Make Cats Free

Задача курса: обучиться и получить набор навыков для обосновывания решения при выборе той или иной архитектуры проектируемой системы.

Описание задачи и требования здесь: Requirements

Задание второй домашки

1. Core Domain Chart
2. Определить bounded-контексты, сделать модель с поддоменами
3. Описать разницу между bounded-контекстами первого урока и второго
4. Найти и выписать характеристики и выбрать один из четырех стилей

Задание третьей домашки

1. Описать структуру системы с архиеткурными стилями
2. Выбрать виды баз данных
3. Выбрать стили коммуникаций
4. Написать ADR

Задание четвертой домашки (рефакторинг)

В этом уроке нам необходимо исправить систему, которую сделали до нас. Т. е. надо из «начальной системы» получить то, что у вас получилось в конце третьей домашки, + изменить систему под новые условия. Для того чтобы было интереснее, в качестве «начальной системы» я предлагаю выбрать один из двух вариантов: Выбираю схему из домашки

1. для каждого удалённого сервиса и связанных с ним сервисов посчитайте значение instability;
2. опишите, какие сервисы и боундед-контексты в каком месте и каким образом будут меняться;
3. спланируйте, как и в какой последовательности будет происходить работа. Можете выбрать одно из двух условий: нет людей, нет ресурсов.

Задание пятой домашки

• Достать спроектированную систему из нулевой недели и сравнить её с текущим результатом. Найти места, которые вы сделали иначе, чем изначально планировали, что в текущем решении отличается от изначального и что лично вам понравилось из решений.

• Выписать идеи и подходы, которые вы хотели бы внедрить в ваших рабочих или других проектах, чтобы мы могли их обсудить и подумать, как лучше всего внедрить каждую из идей или подходов.

Итоги

То, что пригодится

Полноценно сравнивать было-стало не могу, потому что систему в нулевой домашке я не прорабатывал. Формально я представлял её как модульный монолит, но выбор на него пал просто потому, что это самое простое решение.

Если бы попросили описать курс одним предложением, я бы выкатил, что-то типа: Вначале давайте ответим на вопрос: что мы делаем, а не как.

И на самом деле, "сваливание" на слой ниже при решении проблемы свойственно инженерам и/или людям с техническим складом ума.

Она же актуальна и при написании кода. Когда ты не соблюдаешь изоляцию слоев, когда в одном классе решаешь кучу задач (GOD-object), когда открыл класс Class1.cs (потом переименую) и сходу пишешь: здесь кеширования, здесь коммуникация с API, здесь доступ к БД... И все нарушения SOLID от того, что ты не понял доконца, что за проблема перед тобой, и соотвественно не смог её декомпозировать на поддпроблемы. А после: когда путем багов, дебагов, итераций, общения с аналитиками, клиентами ты все таки понял, что за проблема, и что мне "здесь" не сдалось кэширование, что к API обращаться не нужно, что и к БД доступ дожен быть в другом классе, то написанный тобой код начинает драйвить разработку, и не позволяет решать следующие задачи эффективно.

Ключевые инструменты, которые понятно как применять

• ES-диаграмма
• Модель данных
• Context-mapping
• ADR

Из инструментов, которые точно "зайдут", это анализ поведения (ES) и анализ данных, кажется это две ортогональные и базовые оси, которые в большинстве случаев, дадут хорошее представление о системе. А затем выяснение ограничений и требований вместе с анализом домена помогут скорректировать изначальное представление.

Список этапов, как шпаргалка:

1. Анализ поведения
2. Анализ данных
3. Анализ домена
4. Анализ требований сэйк-холдеров и ограничений

Кажется, нужно изучить c4

Помимо представления системы на верхнем уровне то, что было в курсе, хочется погрузиться в методы описания технических деталей и инструментов для этого.

Что не совсем понятно сейчас

Сейчас для меня характеристики имеют совсем абстрактный смысл, сложно определить, что в конткретном случая необходимо, и насколько их влияние сильно на итоговую систему по сравненую с другими (поведение, модель данных и т.д.). Полагаю, что нужно больше уделить внимания на каждую характеристику из основного списка и найти побольше примеров принятий решений на их основе.

Roadmap

Накидал себе черновой roadmap из материалов для доп изучения. Их реально много, но ниже маленький спискок, за что зацепился глаз:

Roadmap

Благодарность

Курс получился очень "богатым"! Представляю, как было сложно систематизировать такой объем знаний, чтобы получился относительно простой и понятный гайд по анализу систем.

Ожидание - реальность полностью совпали, в этом мне помогло прочтение тестового первого урока до покупки.

Изобилие материалов и стиль подачи указывают на стремление автора передать накопленный опыт максимально эффективно, оградив от потенциальных проблем.

Спасибо Антону и всей команде, за огромную и важную работу!