Pull to refresh

Предметно-ориентированное проектирование на самом деле

Reading time12 min
Views30K

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


Под катом я хотел бы рассказать о том, что составляет масштаб, почему Эванса нужно дочитать, почему предметно-ориентированному проектированию 100 лет в обед и кое-что от себя.



Стратегическое проектирование


Четвёртая часть книги Эрика Эванса посвящена стратегическому проектированию. Предметно-ориентированное моделирование как колонны проходят сквозь ваши микросервисы, особенно если они декомпозированы по субдомену. В архитектуре зданий, сооружения не состоят из одной колонны — их строят из множества получая каркас. О том как же получить этот каркас и написана последняя часть Big Blue Book в трёх разделах: взаимодействие между контекстами, дистилляция модели, крупномасштабная структура.


Взаимодействия между контекстами


Отражается следующей схемой


Тип Описание Изображается
ПАРТНЕРСТВО Равные отношения взаимовлияния — две группы разработчиков занимаются отдельно своими ограниченными контекстами, прибегая к взаимодействию с целью достижения общей цели. В таком взаимодействии успеха или провала достигают обе группы.
ОБЩЕЕ ЯДРО (SHARED KERNEL) ОБЩЕЕ ЯДРО часто представляет собой СМЫСЛОВОЕ ЯДРО предметной области (CORE DOMAIN), набор ЕСТЕСТВЕННЫХ ПОДОБЛАСТЕЙ (GENERIC SUBDOMAINS) или то и другое одновременно. Две команды вместе работают над общей частью.
КЛИЕНТ — ПОСТАВЩИК (CLIENT- SUPPLIER) Такие отношения между командами, в которых команда-поставщик является вышестоящей, а команда потребитель нижестоящей. Такие отношения выстраиваются между командами с общим руководством, когда поставщик должен учитывать потребности клиента. Можно видеть, что Клиент-Поставщик очень похож на партнёрство, но в работе команд возникает некоторый перекос, который делает одну из них ведущей.
КОНФОРМИСТ (CONFORMIST) Разновидность поставщик-потребитель, которая требует области подстройки. Возникает в том случае, если вышестоящая команда не имеет мотивации для удолитворения нужд нижестоящей.
ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ (ANTICORRUPTION LAYER) Разновидность отношения конформист, у которой область подстрой выделена в отдельный слой, с полноценной трансляцией для соблюдения правил ограниченного контекста. Возникает в тех случаях, когда разница Единого Языка становится значительной, а синхронизация команд затруднительной.
СЛУЖБА С ОТКРЫТЫМ ПРОТОКОЛОМ (OPEN HOST SERVICE) Разновидность отношения конформист, которая облегчает многочисленные интеграции с вышестоящим контекстом.
ОБЩЕДОСТУПНЫЙ ЯЗЫК (PUBLISHED LANGUAGE) Такой вид отношений команд, который строго запротоколирован в индустрии, что позволяет вообще не зависит от других команд. Отличные примеры общедоступных языков — DICOM.
ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ (SEPARATE WAYS) Случай когда договорится не получается и команды работают полностью отдельно.

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


Назначение карты контекстов — спрогнозировать возможности по развитию ограниченных контекстов. В условиях Enterprise, такая схема позволит правильно подумать над тем, что может бескровно эволюционировать, а где могут возникнуть существенные проблемы. Так, решая проблемы, где-то необходимо прийти к административному ресурсу, где-то чаще повстречаться (может быть провести ряд meet'апов для повышения вовлечённости вышестоящей команда, а иногда пойти по пути отдельного существования.
Если взглянуть на карту взаимодействия между контекстами с точки зрения экономики, то мы строя карту контекстов получаем план производства в организации.


Дистилляция



Дистилляция — деятельность направленная на первоначально получение информации о самых важных частях системы, которая только готовится к проектированию.


Название Описание
Смысловое ядро (Core Domain) Части модели, основные для выполнения главной задачи приложения. Следует подключить к работе над этой частью системы наиболее квалифицированных специалистов, с тем чтобы построить углубленную модель и гибкую архитектуру.
Неспециализированные подобласти (Generic Subdomains) Части модели, которые по отношению к задаче и специализации модели являются вторичными или вспомогательными. Эти части не приносят непосредственной пользы смыслового ядра, и поэтому, следует минимально тратить силы ведущих разработчиков на этих частях модели, в пользу смыслового ядра. Сами неспециализированные подобласти следует посредством рефакторинга вынести в отдельные модули.
Введение в предметную область (Domain Vision Statement) Краткое описание смыслового ядра, описывающие в очень общих чертах различные компоненты будущей систем, так что в описание включалось только то, что однозначно отличает каждую из моделей. Задаёт общее направление работы разработчиков и т.к. не содержит деталей, подходит только для программистов слаженно работающих друг с другом.
Схематическое ядро (Highlighted Core) Описание смыслового ядра в более подробном виде, чем введение в предметную область, необходимое в том случае, когда коммуникация в команде не на высоком уровне. Эванс предлагает два варианта. Первый — дистилляционный документ — краткий документ в несколько страниц, с описанием смыслового ядра и основных взаимодействий между элементами ядра. Второй — разметка ядра — перечисление основных элементов ядра, без разъяснения их роли.
Связанные механизмы (Cohesive Mechanisms) Алгоритмически сложная часть системы, вынесенная за интуитивные интерфейсы в отдельные модули. Такое сокрытие алгоритма позволяет глубже концентрироваться на модели, нежели на том как её обрабатывать.
Декларативный стиль (Declarative Style) Смысловое ядро дистиллированное до такой степени, что может использоваться как декларативная архитектура, приобретая вид доменно-ориентированного языка.
Выделенное ядро (Segregated Core) Несколько итераций рефакторинга смыслового ядра, направленные на Low Coupling и High Cohesion. В результате появляется чётко выделенное ядро и отдельно связанные механизмы и неспециализированные подобласти.
Абстрактное ядро (Abstract Core) Отдельный модуль смыслового ядра, который получается в процессе рефакторига кода с исключением взаимозависимостей и выделением общих абстрактных частей модели. Абстрактное ядро даёт представление об основных понятиях и взаимодействиях, а специализированные модули ссылаются на него.

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


Крупномасштабная структура


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


Название Описание
Метафорический образ системы (System Metaphor) Образ системы (метафора), который позволяет разработчикам и предметным экспертам улучшить согласованность между отдельными элементами системы и ограниченными контекстами.
Уровни разделения обязанностей (Responcibility Layers) Меры по снижению зацепления элементов и повышению связности путём расслоения системы по функциональному назначению. Это в свою очередь позволяет задать порядок и направление взаимодействия между слоями. Выбирая уровни следует исходить из информативности, концептуальной взаимосвязанности, наличия концептуальных контуров.
Уровень знаний (Knowlage Level) Модели могут содержать большую вариабельность, которая квалифицируется ролями или взаимоотношениями между сервисами. Отличается от уровней разделения обязанностей двунаправленным взаимодействием слоёв.
Среда подключаемых компонентов (Pluggable Component Framework) В случае проработанной углубленной модели, наличии абстрактного ядра, система может различные предметные модули могут работать с абстрактным ядром через одни и те же интерфейсы или через применение общедоступного языка.
Эволюционная организация (Evolving Order) Подход, при котором модели и их определения не являются излишне жёсткими, позволяя по мере развития проекта, получения углубленной модели, изменяться архитектуре значительным образом. Применяется при недостаточно детализированных знаниях о предметной области.



В довершение обзора Стратегического моделирования, я бы хотел отметить, что автор Big Blue Book не просто даёт рекомендации по построению системы, а добавляет к системе измерение — разработчиков которые делают эти системы. И причиной этого он несколько раз указывает необходимость слаженной, совместной работы, упоминает Agile и CI, намекая на то что успех предметно-ориентированного проектирование зависит не только лишь от компетентности, но и горизонтального взаимодействия самоорганизующихся разработчиков. Т.е. работа, падающая сверху в виде проработанных таск через иерархию не будет DDD.


Эту мысль я бы хотел пронести через пример из другой области, как я считаю, не лишённой параллелей с разработкой программного обеспечения.


100 лет назад


Авангардная архитектура


Чтобы ещё плотнее понять DDD, его возможности применения, не лишним будет рассмотреть связь с архитектурой зданий, уделив особое внимание общим диалектическим чертам.


Итак, знакомьтесь — конструктивизм в архитектуре:



Самое большое развитие конструктивизм получил в 20е годы, стараниями советских архитекторов. Предвестником этой революционной архитектуры стал известный французский архитектор Ле Корбюзье, провозгласивший свой знаменитый тезис дом - машина для жилья и сформулировавший пять отправных точек архитектуры:


1. Колонна должна стоять свободно в открытом пространстве.
2. Конструктивный каркас здания функционально не зависит от стены и внутренних перегородок.
3. Свободный план не  зависит от  конфигурации наружных стен.
4. Фасад  определяется  внутренней каркасной конструкцией здания.
5. Сад на крыше  раскрывает пространство дома вверх.

Сотни лет архитекторы проектировали коробки, с "правильными" фасадами, а содержание здания планировалось по остаточному принципу. Теперь же всё по-другому — провозглашается единство формы и функции.


Так случилось, что единственным местом, где новый стиль задышал полной грудью, стала молодая страна базирующаяся на новых экономических принципах. Появился запрос, на формирования нового человека, нового уклада жизни. Сама работа архитекторов того времени нам бы показалась очень необычной. Они работали совместно, стараясь поучаствовать во всех проектах, на которые находили время. Они собирались в "группировки", такие как ОСА, АСНОВА, АРУ, ВОПРА. В их работе были признанные авторитеты, но совершенно не было иерархии.


Сама система обучения этих архитекторов в вышей степени интересна, что хорошо можно видеть на примере ВХУТЕМАС. Во-первых, это альтернативное не классическое учебное заведение. Во-вторых, сам учебный процесс был постоен очень необычно — студентам давали возможность с самых необычных сторон подойти к своему делу. В-третьих, структура ВУЗа, преподавания не иерархичная начинающаяся с ректора, а образовалась вокруг авторитета преподавателей. В-четвёртых, в разное время там преподавали такие люди как А. Е. Архипов, А. Д. Древин, В. В. Кандинский, Д. Н. Кардовский, Н. А. Ладовский, В. Ф. Кринский, Л. М. Лисицкий, К. С. Мельников, П. В. Митурич, Н. И. Нисс-Гольдман, А. М. Нюренберг, А. М. Родченко, В. Ф. Степанова, В. Е. Татлин, В. А. Фаворский, П. А. Флоренский, Ф. О. Шехтель, П. И. Келин, А. Ф. Лолейт, И. С. Ефимов, Н. В. Докучаев, Г. О. Чириков и другие. В.В. Кандинский — это авторо той самой Композиции VIII:


Composition VIII


Совпадение?


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


Дом-коммуна на Орджоникидзе


В 1928 молодой архитектор Иван Сергеевич Николаев получил заказ на проектирование студенческого дома-коммунны на 2000 мест от Текстильстроя. Дом на улице Орджоникидзе стал первым домом-коммунной в Москве. Приступая к проектированию, Николаев опросил студентов о, их быте, режиме дня (очень напоминает EventStorming).



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


Что же интересного в этом здании со стороны прогера знакомого с DDD? Начну с одного из фасадов.



Для начала, можно заметить что тут соблюдены все принципы Ле Корбюзье. Здание стоит на колоннах — под ним можно пройти, оставить машину. И это пример продуманного интерфейса и UX, не правда ли. Сами колонны являются основанием для каркаса здания, позволяя проводить свободную планировку. Фасад здесь вторичен и функционален — максимум остекления для освещения. Совсем так же как в разработке ПО, мы проектируем предметную модель, а затем остальные части системы.



Все части здания предельно функциональны — для каждого вида деятельности отдельный корпус или его часть. В одном корпусе студенты просыпаются, в другом принимают душ, идут в столовую, оттуда на занятия, потом кружки и библиотека и снова спать. Что тут необычно — это то, что здание не построено коробкой и разбито на корпусы. Каждая часть здания, отвечающая за определённую деятельность спроектирована отдельно, а всё вместе соединенно в потрясающую композицию. Позволю себе тут метафору с микросервисами, которые составляют ландшафт.


Связь с нашей деятельностью — самая прямая. Николаев подошёл к решению задач с тех же позиций, как когда мы планируем сделать крупную систему с использованием принципов предметно-ориентированного проектирования. Он провёл опрос студентов, предметно спроектировал каждый вид их деятельности, и скомпоновал должным образом. Продуманная история о том, как студенты проживают свою жизнь в таком общежитии — и есть продуманный UX. Сам каркас здания во многом — крупномасштабная структура, которая задавала точки расширения и основной фокус работ. Отсутствие фасада в привычном смысле — вместо этого стены строятся вокруг назначения конкретной части здания. И это полностью соответствует проектированию на основе модели в информационных системах.


Куда делся конструктивизм?


Эти великолепные шедевры авангарда, можно видеть во многих крупнейших городах России и прилежащих стран. Ещё больше можно увидеть его в современных зданиях и даже небоскрёбах. Но в целом конструктивизм существовал в основном в двадцатые годы прошлого столетия. Спрос на данные работы сменился ужесточениями, а в отношении некоторых даже репрессивными мерами.


На съезде архитекторов 1932 года, конструктивизм был признан излишне левым, не соответствующим интересам партии и нового времени — мещанство победило. Если не касаться совсем уж политики, то важно сказать что случилось после съезда. Архитектурные группировки были распущены, а проектная деятельность сосредоточилась в руках одного института. Т.е. из горизонтальной структуры образовалась иерархия строго подчинения. Так началась история ампира и хрущёвок, но это уже не то что нам интересно.


Подытоживаю


Для чего можно использовать Domain Driven Design?


  • Если проработать техническую часть (контексты, агрегаты и т.п.), можно сделать несколько хороших модулей, которые будут вполне адаптивны к изменениям.
  • Если проработать ряд модулей, то можно заняться стратегическим проектированием (кратко описано выше).
  • Если есть стратегический проект, можно сделать очень достойную микросервисную архитектуру.
  • Микросервисная архитектура сделанная по DDD согласно закону Конвея будет повторять структуру организации.
  • Модель организации может быть использована для ML-механизмов, контроля качества, автоматизации.
  • Организация
    • станет более конкурентноспособной;
    • простой труд станет менее востребован, высококвалифицированный более востребованный.

Если дойти до конца, то возможно разработчики будут уже не просто сервисом к бизнесу, а будут менять его. И в тот момент, когда количество таких локальных изменений станет достаточно большим, изменится и сама ткань общества. Во многом, это и есть продолжение того, что сейчас называют четвёртой промышленной революцией по Швабу, ведь в результате работы мы получаем виртуальную модель производства.


Предметно-ориентированное проектирование на самом деле


Я привёл в пример Эванса и авангардистов, чтобы показать, что сложности с DDD и его смысл, не в техническом аспекте, а в экономическом и несколько политическом. Успех больших проектов во многом зависит от того, насколько команда(ы) разобщены и подчиненны иерархии. Архитектор в одно лицо не сможет сделать огромный проект и следить за корректностью его реализации. А армия аналитиков и продактов даже не сможет задать нужные вопросы, ведь они решают свою задачу показателей, не владеют стратегическим проектированием, часто лишены технической экспертизы. В подтверждение может выступать один из принципов AgileСамые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.


Предметно-ориентированное проектирование — это левая архитектура, требующая сильные самоорганизующиеся коллективы, которые устроены максимально горизонтальным способом. И эту задачу должен решать настоящий Agile во всей организации. Так же, для это подхода будет важным не зависеть от решения начальства напрямую, по поводу каких-либо технических моментов.


Если вас не поддерживает вышестоящее руководство, если вы один в поле воин, если ландшафт технологической платформы не подкрепляет ожиданий потребителей, если вы не связаны с каким-либо реальным производством — у вас не будет настоящего DDD, настоящих микросервисов и к целям выше прийти не получится. Однако это не означает элитности подхода — его просто не получится претворить в жизнь в его самом полном виде. И тогда к предметно-ориентированному проектированию можно попытаться создавать предпосылки, и возможно тогда появится возможность попробовать.


Как Ле Корбюзье дал архитекторам общие принципы архитектуры зданий, с помощью которых те меняли быт людей, так и Эрик Эванс описал DDD и принципы борьбы со сложностью предметной области, которые в полной своей совокупности могут помогать бизнесу. Самое главное в этом подходе — это работать над командой профессионалов, меньше думать о том, чему могут научить вас, а чему вы можете научится вместе с командой!


САМООРГАНИЗАЦИЯ ИЛИ ВАРВАРСТВО




P.S. Искренне советую посетить экскурсии по конструктивизму. Рассказы об этих зданиях, как будто об архитектуре микросервисов у себя! Особенно если вы дочитали Эванса...


Ссылки


Tags:
Hubs:
+11
Comments10

Articles