19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

КАК СТАТЬ АВТОРОМ Оркестрируешь небось? Расскажи всем в Сезоне Kubernet…

m1rko 25 октября 2018 в 16:29
DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это
вместе
Анализ и проектирование систем*, Проектирование и рефакторинг*
Перевод
Автор оригинала: Herberto Graça

Эта статья — часть «Хроники архитектуры программного обеспечения», серии статей об

архитектуре ПО. В них я пишу о том, что узнал об архитектуре программного
обеспечения, что я думаю об этом и как использую знания. Содержание этой статьи
может иметь больше смысла, если вы прочитаете предыдущие статьи в серии.
После окончания университета я начал работать учителем средней школы, но несколько
лет назад уволился и пошёл в разработчики программного обеспечения на полный
рабочий день.
С тех пор я всегда чувствовал, что мне нужно восстановить «потерянное» время и
https://habr.com/ru/post/427739/ 1/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

узнать как можно больше, как можно быстрее. Поэтому я стал немного увлекаться
экспериментами, много читать и писать, уделяя особое внимание дизайну и архитектуре
программного обеспечения. Вот почему я пишу эти статьи, чтобы помочь себе в
обучении.
+27 71K 336 14 +14

В последних статьях я рассказывал о многих концепциях и принципах, которые я узнал,

и немного о том, как я рассуждаю о них. Но я представляю их как фрагменты одного
большого паззла.
Эта статья о том, как я собрал воедино все эти фрагменты. Кажется, я должен дать им
название, так что назову их явной архитектурой (explicit architecture). Кроме того, все
эти концепции «испытаны в бою» и используются в продакшне на высоконадёжных
платформах. Одна из них — SaaS-платформа электронной коммерции с тысячами
интернет-магазинов по всему миру, другая — торговая площадка, работающая в двух
странах с шиной сообщений, которая обрабатывает более 20 миллионов сообщений в
месяц.

Фундаментальные блоки системы

Инструменты
Подключение инструментов и механизмов доставки к ядру приложения
Порты
Основные или управляющие адаптеры
Вторичные или управляемые адаптеры
Инверсия управления
Организация ядра приложения
Уровень приложения
Уровень домена
Сервисы домена
Модель домена
Компоненты
Разъединение компонентов
Срабатывание логики в других компонентах
Получение данных от других компонентов
Общее хранилище данных для компонентов
Отдельное хранение данных для компонента
https://habr.com/ru/post/427739/ 2/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Поток управления

Фундаментальные блоки системы

Начнём с того, что вспомним архитектуры EBI и Ports & Adapters. Обе они явно
разделяют внутренний и внешний код приложения, а также адаптеры для соединения
внутреннего и внешнего кода.
Кроме того, архитектура Ports & Adapters явно определяет три фундаментальных блока
кода в системе:

То, что позволяет запускать пользовательский интерфейс, независимо от его типа.

Системная бизнес-логика или ядро приложения. Его использует UI для
совершения реальных транзакций.
Код инфраструктуры, который соединяет ядро нашего приложения с такими
инструментами, как БД, поисковая система или сторонние API.

Ядро приложения — самое главное, о чём нужно думать. Этот код позволяет совершать
реальные действия в системе, то есть это и ЕСТЬ наше приложение. С ним могут
https://habr.com/ru/post/427739/ 3/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

работать несколько пользовательских интерфейсов (прогрессивное веб-приложение,

мобильное приложение, CLI, API и др.), всё выполняется на одном ядре.
Как можно себе представить, типичный поток выполнения идёт от кода в UI через ядро
приложения к коду инфраструктуры, обратно к ядру приложения и, наконец, ответ
доставляется в UI.

Инструменты

Вдали от самого важного кода ядра есть ещё инструменты, которые использует
приложение. Например, ядро БД, поисковая система, веб-сервер и консоль CLI (хотя
последние два также являются механизмами доставки).

https://habr.com/ru/post/427739/ 4/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Кажется странным отнести консоль CLI в тот же тематический раздел, что и СУБД, ведь у
них разное предназначение. Но фактически и то, и другое — инструменты,
используемыми приложением. Ключевое различие в том, что консоль CLI и веб-сервер
говорят приложению что-то сделать, ядро СУБД, наоборот, получает команды от
приложения. Это очень важное различие, поскольку оно сильно влияет на то, как мы
пишем код для соединения этих инструментов с ядром приложения.
Подключение инструментов и механизмов доставки к ядру приложения

Блоки кода, соединяющие инструменты с ядром приложения, называются адаптерами

(архитектура Ports & Adapters). Они позволяют бизнес-логике взаимодействовать с
определённым инструментом, и наоборот.
Адаптеры, которые говорят приложению что-то делать, называются первичными или
управляющими адаптерами, в то время как адаптеры, которым приложение говорит
что-то делать, называются вторичными или управляемыми адаптерами.
Порты

Однако эти адаптеры создаются не случайно, а чтобы соответствовать конкретной точке

входа в ядро приложения, порту. Порт — это не более чем спецификация того, как
инструмент может использовать ядро приложения или наоборот. В большинстве языков
https://habr.com/ru/post/427739/ 5/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

и в простейшем виде этот порт будет интерфейсом, но фактически он может быть

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

Основные или управляющие адаптеры оборачиваются вокруг порта и используют его

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

Другими словами, наши управляющие адаптеры являются контроллерами или

консольными командами, они внедряются в их конструктор с некоторым объектом,
класс которого реализует интерфейс (порт), который требует контроллер или
консольная команда.
В более конкретном примере порт может быть интерфейсом службы или интерфейсом
репозитория, который требуется контроллеру. Конкретная реализация сервиса,
репозитория или запроса затем внедряется и используется в контроллере.
https://habr.com/ru/post/427739/ 6/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

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

В отличие от управляющих адаптеров, которые оборачиваются вокруг порта,

управляемые адаптеры реализуют порт, интерфейс, а затем вводятся в ядро
приложения там, где требуется порт (с указанием типа).

Например, у нас есть нативное приложение, которому необходимо сохранять данные.

Мы создаём persistence-интерфейс с методом сохранения массива данных и методом
удаления строки в таблице по её ID. С этого момента везде, где приложение должно
сохранить или удалить данные, мы будем требовать в конструкторе объект, который
реализует persistence-интерфейс, который мы определили.
Теперь создаём адаптер, специфичный для MySQL, который будет реализовывать этот
интерфейс. У него будут методы для сохранения массива и удаления строки в таблице, и
мы введём его везде, где требуется persistence-интерфейс.
https://habr.com/ru/post/427739/ 7/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Если в какой-то момент мы решим изменить поставщика базы данных, например, на

PostgreSQL или MongoDB, нам просто нужно создать новый адаптер, который реализует
persistence-интерфейс, специфичный для PostgreSQL, и внедрить новый адаптер вместо
старого.
Инверсия управления

Характерной особенностью этого шаблона является то, что адаптеры зависят от

конкретного инструмента и конкретного порта (путём реализации интерфейса). Но наша
бизнес-логика зависит только от порта (интерфейса), который предназначен для
удовлетворения потребностей бизнес-логики и не зависит от конкретного адаптера или
инструмента.

Это означает, что зависимости направлены к центру, то есть налицо инверсия

принципа управления на архитектурном уровне.
Хотя опять же, крайне важно, чтобы порты создавались в соответствии с
потребностями ядра приложения, а не просто имитировали API инструментов.
Организация ядра приложения

Архитектура Onion подхватывает слои DDD и включает их в архитектуру портов и

https://habr.com/ru/post/427739/ 8/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

адаптеров. Эти уровни предназначены для того, чтобы внести некоторый порядок в
бизнес-логику, внутреннюю часть «шестиугольника» портов и адаптеров. Как и раньше,
направление зависимостей — к центру.
Уровень приложения (прикладной уровень)

Варианты использования — это процессы, которые можно запустить в ядре одним или
несколькими пользовательскими интерфейсами. Например, в CMS может быть один UI
для обычных пользователей, другой независимый UI для администраторов CMS, ещё
один интерфейс CLI и веб-API. Эти UI (приложения) могут инициировать уникальные или
общие варианты использования.
Варианты использования определяются на прикладном уровне — первом уровне DDD и
архитектуры Onion.

Этот уровень содержит службы приложений (и их интерфейсы) в качестве объектов

первого класса, а также содержит интерфейсы портов и адаптеров (порты), которые
включают интерфейсы ORM, интерфейсы поисковых систем, интерфейсы обмена
сообщениями и т. д. В случае, когда мы используем шину команд и/или шину запросов,
на этом уровне находятся соответствующие обработчики команд и запросов.
Службы приложений и/или обработчики команд содержат логику развёртывания
https://habr.com/ru/post/427739/ 9/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

варианта использования, бизнес-процесс. Как правило, их роль следующая:

1. использовать репозиторий для поиска одной или нескольких сущностей;

2. попросить эти сущности выполнить некоторую логику домена;
3. и использовать хранилище, чтобы заново сохранить сущности, эффективно сохраняя
изменения данных.

Обработчики команд можно использовать двумя способами:

1. Они могут содержать логику для выполнения варианта использования;

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

Какой подход использовать — зависит от контекста, например:

У нас уже есть службы приложений и теперь добавляется шина команд?

Позволяет ли шина команд указывать какой-либо класс/метод в качестве
обработчика, либо необходимо расширить или реализовать существующие классы
или интерфейсы?

Этот уровень также содержит инициирование событий приложения, которые

представляют собой некоторый результат варианта использования. Эти события
запускают логику, являющуюся побочным эффектом варианта использования, например,
отправку сообщений электронной почты, уведомление стороннего API, отправку пуш-
уведомления или даже запуск другого варианта использования, принадлежащего
другому компоненту приложения.
Уровень домена

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

https://habr.com/ru/post/427739/ 10/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Сервисы домена

Как я уже упоминал выше, роль службы приложений:

1. использовать репозиторий для поиска одной или нескольких сущностей;

2. попросить эти сущности выполнить некоторую логику домена;
3. и использовать хранилище, чтобы заново сохранить сущности, эффективно сохраняя
изменения данных.

Но иногда мы сталкиваемся с некоторой доменной логикой, которая включает в себя

различные сущности одинакового или разных типов, и эта доменная логика не
принадлежит самим сущностям, то есть логика не является их прямой ответственностью.
Поэтому нашей первой реакцией может быть размещение этой логики вне сущностей в
службе приложений. Однако это означает, что в других случаях логика домена не будет
использоваться повторно: логика домена должна оставаться вне уровня приложения!
Решение состоит в том, чтобы создать доменную службу, роль которой состоит в
получении набора сущностей и выполнении на них некоторой бизнес-логики. Доменная
служба принадлежит к доменному уровню и поэтому ничего не знает о классах на
https://habr.com/ru/post/427739/ 11/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

прикладном уровне, таких как службы приложений или репозитории. С другой стороны,
она может использовать другие доменные службы и, конечно же, объекты модели
домена.
Модель домена

В самом центре находится модель домена. Она не зависит ни от чего за пределами

этого круга и содержит бизнес-объекты, что-то представляющие в домене. Примерами
таких объектов являются, прежде всего, сущности, а также объекты-значения (value
objects), перечисления (enums) и любые объекты, используемые в модели домена.
В модели домена «живут» также события домена. Когда определённый набор данных
изменяется, то инициируются эти события, которые содержат новые значения
изменённых свойств. Эти события идеально подходят, например, для использования в
модуле регистрации событий (event sourcing).
Компоненты

До сих пор мы изолировали код по слоям, но это слишком подробная изоляция кода. Не
менее важно посмотреть на картину более общим взглядом. Речь идёт о разделении
кода по поддоменам и связанным контекстам в соответствии с идеями Роберта
Мартина, выраженными в screaming-архитектуре [то есть архитектура должна
«кричать» о самом приложении, а не о том, какие фреймворки в нём используются —
прим. пер.]. Здесь говорят об организации пакетов по функциям или по компонентам, в
не по слоям, и это довольно хорошо объяснил Саймон Браун в статье «Пакеты по
компонентам и тестирование в соответствии с архитектурой» в своём блоге:

https://habr.com/ru/post/427739/ 12/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Я сторонник организации пакетов по компонентов и хочу бесстыдно изменить

диаграмму Саймона Брауна следующим образом:

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

https://habr.com/ru/post/427739/ 13/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Разъединение компонентов

Так же, как в мелкозернистых единицах кода (классы, интерфейсы, трейты, миксины и
проч.), крупные единицы (компоненты) выигрывают от слабого сцепления и плотной
связности.
Чтобы разъединить классы, мы используем инъекцию зависимостей, вводя зависимости
в класс, а не создавая их внутри класса, а также инверсию зависимостей, делая класс
зависимым от абстракций (интерфейсов и/или абстрактных классов) вместо конкретных
классов. Это означает, что зависимый класс ничего не знает о конкретном классе,
который будет использовать, у него нет ссылки на полное имя классов, от которых он
зависит.
Точно так же в полностью разъединенных компонентах каждый компонент ничего не
знает ни о каком другом компоненте. Другими словами, у него нет ссылки на какой-либо
мелкозернистый блок кода из другого компонента, даже на интерфейс! Это означает,
что инъекции зависимостей и инверсии зависимостей недостаточно для разделения
компонентов, нам понадобятся какие-то архитектурные конструкции. Могут
понадобиться события, общее ядро, согласованность в конечном счёте (eventual
consistency) и даже служба обнаружения сервисов (discovery service)!

https://habr.com/ru/post/427739/ 14/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Срабатывание логики в других компонентах

Когда один из наших компонентов (компонент B) должен что-то делать всякий раз, когда
что-то ещё происходит в другом компоненте (компонент A), мы не можем просто
сделать прямой вызов из компонента A в класс/метод компонента B, потому что тогда A
будет связан с B.
Однако мы можем использовать диспетчер событий для отправки события приложения,
которое будет доставлено любому компоненту, прослушивающему его, включая B, и
прослушиватель событий в B вызовет желаемое действие. Это означает, что компонент
A будет зависеть от диспетчера событий, но будет отделён от компонента B.
Тем не менее, если само событие «живёт» в A, это означает, что B знает о
существовании А и связан с ним. Чтобы удалить эту зависимость, мы можем создать
библиотеку с набором функциональных возможностей ядра приложения, которые будут
совместно использоваться всеми компонентами — общее ядро. Это означает, что оба
компонента будут зависеть от общего ядра, но будут отделены друг от друга. Общее
ядро содержит функциональные возможности, такие как события приложения и домена,
но оно также может содержать объекты спецификации и всё, что имеет смысл
совместно использовать. При этом оно должно быть минимального размера, поскольку
любые изменения в общем ядре повлияют на все компоненты приложения. Кроме того,
если у нас есть polyglot-система, скажем, экосистема микросервисов на разных языках,
то общее ядро не должно зависеть от языка, чтобы его понимали все компоненты.
Например, вместо общего ядра с классом событий оно будет содержать описание
события (то есть имя, свойства, возможно, даже методы, хотя они были бы более
https://habr.com/ru/post/427739/ 15/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

полезны в объекте спецификации) на универсальном языке вроде JSON, чтобы все

компоненты/микросервисы могли интерпретировать его и, возможно, даже
автоматически генерировать свои собственные конкретные реализации.
Этот подход работает как в монолитных, так и в распределённых приложениях, таких как
экосистемы микросервисов. Но если события можно доставить только асинхронно, то
этого подхода недостаточно для контекстов, где логика запуска в других компонентах
должна срабатывать немедленно! Здесь компоненту A потребуется делать прямой
HTTP-вызов к компоненту B. В этом случае, чтобы разъединить компоненты, нам
понадобится служба обнаружения. Компонент A спросит у неё, куда отправить запрос,
чтобы инициировать желаемое действие. Как вариант, сделать запрос к службе
обнаружения, которая передаст его соответствующей службе и в конечном счёте
возвратит ответ инициатору запроса. Этот подход связывает компоненты со службой
обнаружения, но не связывает их друг с другом.
Получение данных от других компонентов

Как я вижу, компоненту не разрешено изменять данные, которыми он не «владеет», но

он может запрашивать и использовать любые данные.
Общее хранилище данных для компонентов

Если компонент должен использовать данные, принадлежащие другому компоненту

(например, компонента биллинга должен использовать имя клиента, которое
принадлежит компоненту аккаунтов), то он содержит объект запроса к хранилищу этих
данных. То есть компонент биллинга может знать о любом наборе данных, но должен
использовать «чужие» данные только для чтения.
Отдельное хранение данных для компонента

В этом случае применяется тот же шаблон, но уровень хранения данных становится

сложнее. Наличие компонентов с собственным хранилищем данных означает, что
каждое хранилище данных содержит:

Набор данных, которыми компонент владеет и может изменить, сделав его

единственным источником истины;
Набор данных, который является копией данных других компонентов, которые он не
может изменить сам по себе, но они необходимы для функциональности
компонента. Эти данные должны обновляться всякий раз, когда они изменяются в
компоненте владельца.
https://habr.com/ru/post/427739/ 16/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Каждый компонент создаст локальную копию необходимых ему данных из других

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

Как я уже сказал выше, поток управления идёт от пользователя в ядро приложения, к
инструментам инфраструктуры, затем опять в ядро приложения — и обратно к
пользователю. Но как именно классы работают вместе? Кто от кого зависит? Как мы их
составляем?
Как Дядя Боб в своей статье о «чистой» архитектуре (Clean Architecture), я постараюсь
объяснить поток управления схемами UMLish…
Без шины команд/запросов

Если мы не используем шину команд, контроллеры будут зависеть либо от службы

приложения, либо от объекта Query.
[Дополнение 18.11.2017] Я полностью пропустил DTO, который использую для возврата данных из запроса,
поэтому сейчас добавил его. Спасибо MorphineAdministered, который указал на пробел.

https://habr.com/ru/post/427739/ 17/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

На приведённой выше диаграмме мы используем интерфейс для службы приложений,

хотя можем утверждать, что он на самом деле не нужен, так как служба приложений
является частью нашего кода приложения. Но мы не хотим менять реализацию, хотя и
можем провести полный рефакторинг.
Объект Query содержит оптимизированный запрос, который просто возвращает
некоторые необработанные данные, которые будут показаны пользователю. Эти данные
возвращаются в DTO, который внедрён в ViewModel. Эта ViewModel может иметь какую-
то логику View и будет использоваться для заполнения View.
С другой стороны, служба приложений содержит логику вариантов использования,
которая срабатывает, когда мы хотим что-то сделать в системе, а не просто просмотреть
некоторые данные. Служба приложений зависит от репозиториев, которые возвращают
сущности, содержащие логику, которую необходимо инициировать. Она может также
зависеть от доменной службы для координации процесса домена в нескольких
сущностях, но это редкий случай.
После разбора случая использования, сервис приложения может уведомить всю
систему, что произошёл случай использования, тогда он будет зависеть ещё от
диспетчера событий, чтобы инициировать событие.
https://habr.com/ru/post/427739/ 18/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Интересно отметить, что мы размещаем интерфейсы как на persistence-движке, так и на

репозиториях. Это может показаться излишним, но они служат разным целям:

Persistence-интерфейс является уровнем абстракции над ORM, так что мы можем

поменять ORM без изменений в ядре приложения.
Интерфейс репозитория является абстракцией над самим persistence-движком.
Допустим, мы хотим переключиться с MySQL на MongoDB. В этом случае
persistence-интерфейс может остаться тем же, а если мы хотим продолжить
использовать тот же ORM, даже адаптер сохраняемости останется тем же самым.
Тем не менее, язык запросов совершенно другой, поэтому мы можем создавать
новые репозитории, которые используют один и тот же механизм сохранения,
реализуют одни и те же интерфейсы репозитория, но строят запросы, используя
язык запросов MongoDB вместо SQL.

C шиной команд/запросов

В случае, если наше приложение использует шину команд/запросов, диаграмма

остаётся практически такой же, за исключением того, что контроллер теперь зависит от
шины, а также от команд или запросов. Здесь создаётся экземпляр команды или
запроса и передаётся шине, которая найдёт соответствующий обработчик для получения
и обработки команды.
На приведённой ниже схеме обработчик команд использует службу приложений. Но это
не всегда необходимо, ведь в большинстве случаев обработчик будет содержать всю
логику варианта использования. Нам нужно лишь извлечь логику из обработчика в
отдельную службу приложений, если требуется повторно использовать ту же логику в
другом обработчике.
[Дополнение 18.11.2017] Я полностью пропустил DTO, который использую для возврата данных из запроса,
поэтому сейчас добавил его. Спасибо MorphineAdministered, который указал на пробел.

https://habr.com/ru/post/427739/ 19/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Вы могли заметить, что нет никаких зависимостей между шиной, командой, запросом и
обработчиками. По сути, они не должны знать друг о друге, чтобы обеспечить хорошее
разъединение. Способ направления шины на конкретный обработчик для обработки
команды или запроса настраивается в простой конфигурации.
В обоих случаях все стрелки — зависимости, которые пересекают границу ядра
приложения — указывают внутрь. Как объяснялось ранее, это фундаментальное правило
архитектуры Ports & Adapters, архитектуры Onion и чистой архитектуры Clean.

Заключение

Как всегда, цель состоит в том, чтобы получить разъединённую кодовую базу с высокой
связностью, в которой можно легко, быстро и безопасно производить любые изменения.
Планы бесполезны, но планирование — это всё. — Эйзенхауэр
https://habr.com/ru/post/427739/ 20/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Эта инфографика — карта концептов. Знание и понимание всех этих концептов помогает
спланировать здоровую архитектуру и работоспособное приложение.
Однако:
Карта — это не территория. — Альфред Корзыбский
Другими словами, это всего лишь рекомендации! Приложение — это территория,
реальность, конкретный вариант использования, где нужно применить наши
знания, и именно оно определяет, как будет выглядеть настоящая архитектура!
Мы должны понимать все эти закономерности, но также всегда нужно думать и
понимать, что именно нужно нашему приложению, как далеко мы можем зайти
ради разъединения и связности. Это решение зависит от множества факторов,
начиная с функциональных требований проекта, до сроков разработки приложения,
срока его службы, опыта команды разработчиков и так далее.
Вот так я всё это для себя представляю.
Эти идеи немного подробнее рассматриваются в следующей статье: «Больше, чем
просто концентрические слои».
Теги: DDD, Hexagonal, Onion, Clean, CQRS, Screaming Architecture, Clean Architecture,
архитектура приложения
Хабы: Анализ и проектирование систем, Проектирование и рефакторинг

Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Электропочта

1271 0
Карма Рейтинг
Анатолий Ализар @m1rko
автор, переводчик, редактор
https://habr.com/ru/post/427739/ 21/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Комментарии 14
mkuzmin
25.10.2018 в 18:00
Буду рад, если посмотрите мою книгу на эту же тему и пототип.
+1 Ответить
claygod
25.10.2018 в 21:15
В своей книге на странице про чистую архитектуру вы написали: Use Case не могут
вызывать друг-друга. Что вы под этим подразумеваете? Интеракторы не могут общаться
между собой?
0 Ответить
mkuzmin
25.10.2018 в 21:23
Полная цитата:
Use Case не могут вызывать друг-друга.
При взгляде на код сценария мы должны видеть все его шаги.
Никто не запрещает выносить общий код в службы(service).
Речь идет о системе по модели запрос-ответ.
Интерактор — нечто, что обрабатывает некое событие.
Например, запрос пользователя или сообщение от сторонней системы.
В этом контесте интеракторы не общаются между собой напрямую.
Естественно, что пользователь может передать данные от одного интерактора другому.
Да, итеракторы не вызавают друг-друга, но могут разделять логику через сервисы.
0 Ответить
claygod
25.10.2018 в 22:31
Я считаю, что в пределах слоя все сущности могут совершенно спокойно общаться
между собой, если же нет, то по сути вы этот слой разбиваете на кучу слоёв, которые
между собой должны общаться согласно общих правил чистой архитектуры. Если же
обсуждать именно запрос-ответ, то тогда кого спросили, тот и ответил, а всё остальное
«общение» интерактора инкапсулировано (не видно).
Пишу это конечно не ради того, чтобы поспорить, а скорее поделиться своим видением.
Вот «горячий» пример из моей практики: данные через входной шлюз поступают на
слой сценариев, проходят сквозь «каналы и фильтры» и выходят через выходной шлюз.
https://habr.com/ru/post/427739/ 22/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Это конечно не запрос-ответ, но хорошо иллюстрирует, что на слое сценариев логика

задействует далеко не одну сущность.
В любом случае спасибо за книгу и желание поделиться своим опытом.
0 Ответить
mkuzmin
25.10.2018 в 22:47
Конечно, интерактор может использовать несколько Сущностей, Служб.
Может не совсем удачная, но аналогия.
Интерактор — это как целая программа, бинарник. Она, как и другие, может
использовать разделяемые библиотки. Пользователь может объединять их с момощью
перенаправления потоков ввода-вывода.
Если остались вопросы, то лучше уже в личку.
0 Ответить

VolCh
26.10.2018 в 12:21
Как по мне, то общения программных сущностей (в широком смысле слова) на одном
слое стоит избегать за исключением доменного слоя. Общую логику или выносить на
слои ниже, или на слое выше создавать какой-то оркестратор или координатор.
0 Ответить

DexterHD
26.10.2018 в 13:03
В целом перевод хороший. В начале вообще супер, под конец немного путано на мой взгляд.
Автором (без претензий к переводчику) на мой взгляд упущены некоторые важные
концепции.
Например ничего не сказано про анемичную модель домена (Anemic Domain Model). Мартин
Фаулер и некоторые другие эксперты считают такую модель анти-паттерном, который на
корню убивает все преимущества ООП. (Предлагается рассматривать, бизнес-модель не как
класс с сеттерами и геттерами, а как набор классов, функций и т.д. тесно
взаимодействующих друг с другом. В данной модели важно в первую очередь поведение а не
данные).
Так же не совсем раскрыта тема ограниченных контекстов, а это очень важная тема.
Ее понимание ключ к знанию о том, где можно скопировать данные и создать новый объект/
класс/значение, а где дублирование кода — явное зло.
Если быть конкретнее, Сущность (Entity) вообще ни как не выражается внутри кода. В
зависимости от Ограниченного Контекста (Bounded Context), внутри кода Entity может быть
https://habr.com/ru/post/427739/ 23/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

представлена как простым типом типа ID, так и объектом-значенем (Value Object) или даже
целым Агрегатом (Agregate).
Например в одном контексте сущность Consumer может быть агрегатом Consumer с кучей
бизнес-логики, а в другом контексте всего лишь полем consumer_id, или value-object-ом
Consumer хранящим только несколько интересующих нас полей.
0 Ответить
VolCh
26.10.2018 в 13:18
> Если быть конкретнее, Сущность (Entity) вообще ни как не выражается внутри кода.
Если выражаться языком DDD и ООП, то Entity DDD представляется обычно объектом со
сложным поведением, возможно агрегирующим другие Entity. ValueObject или просто
значения не представляют Entity.
Другое дело, что сущность предметной области (не путать с Entity в DDD) в одном Bounded
Context может представляться Entity, а в другом ValueObject, при этом ValueObject может
иметь ссылку на Entity из другого Bounded Context, а может не иметь.
0 Ответить
DexterHD
26.10.2018 в 18:06

объектом со сложным поведением,

Я интерпретирую знания о DDD немного по другому. Но это все вопрос исключительно как
раз «единого языка» и правильности перевода и интерпретации. В моем понимании,
объект со сложным поведением (а точнее набор этих объектов) называется «Модель
Предметной Области». Эта модель может состоять не из одного класса, но там будут и
классы отражающие саму сущность и объекты-значения и вспомогательные классы и
константы и т.п.
возможно агрегирующим другие Entity. ValueObject или просто значения не
представляют Entity.
Это в моей картине мира называется Агрегат.
Другое дело, что сущность предметной области (не путать с Entity в DDD)
Предметная область — это буквально Domain. Entity — сущность предметной области. Это
все из DDD, что значит не путать с DDD? Если вы о чем то еще, не о DDD то о чем? Я если
https://habr.com/ru/post/427739/ 24/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

честно тут вас не понял.

в одном Bounded Context может представляться Entity, а в другом ValueObject, при
этом ValueObject может иметь ссылку на Entity из другого Bounded Context, а может не
иметь.
Я и говорю, в одном Bounded Context entity может являться Агрегатом и собритать в себе
все остальные, в другом просто ValueObject-ом, который в себе будет хранит ссылку на
сущность.
По крайней мере Фаулер на конференциях где он упоминает DDD говорил именно так.
0 Ответить
emacsway
29.10.2018 в 09:55
По вопросам управления бизнес-логикой и логикой приложения, статья, конечно,
вызывает ряд вопросов, но это все становится ожидаемым, если учесть контекст статьи:
«я пишу эти статьи, чтобы помочь себе в обучении.» Момент неполного раскрытия
вопросов присутствует, но это неизбежно на стадии обретения опыта. Сам факт
обретения новых горизонтов знаний уже сам по себе вызывает похвалу.
0 Ответить
DexterHD
29.10.2018 в 11:04
Конечно, я и не спорю. А главное вектор выбран правильный imho. Мало кто вообще
знает о том что в данной статье описано и интересуется данными вопросами. Больше
50% на собеседованиях (из личного опыта) понятия не имеют о тех принципах и
понятиях которые в данной статье описаны. В голове зачастую понятийная каша. А это
конечно очень плохо. Особенно если об этом не знают люди претендующие на уровень
senior. Я делаю скидку на то что область наша достаточно молодая и большинство
разработчиков достаточно молоды. :)
0 Ответить

VolCh
31.10.2018 в 11:39
Есть предметная область, в ней есть в ней сущности с отношениями, есть процессы, есть
события — это не DDD, это по сути термины для проанализированных и
систематизированных объективных фактов, рабочие термины аналитиков, не
разработчиков.
DDD же осуществляет маппинг этих терминов на средства выбранного ЯП, очень часто
ООЯП. И вот тут объективная сущность предметной области субъективно моделируется
разного рода объектами в зависимости от контекста. И объективная сущность может
https://habr.com/ru/post/427739/ 25/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

моделироваться в ООЯП как DDD Entity а может как DDD ValueObject, а может как
скалярное значение. DDD частично позаимствовала термины из анализа, но
однозначного соответствия нет. Грубо говоря, если аналитик выделил в предметной
области какую-то сущность, это ещё не значит что в нашей системе она будет
представлена как DDD Entity в "папочке" Domain.
И я сомневаюсь, что Фаулер говорил " entity может являться Агрегатом и собритать в
себе все остальные, в другом просто ValueObject-ом", скорее он говорил "entity
(объективная сущность) может быть представлена ...". Человек (физическое лицо) —
например, это сущность, но он может быть представлен в DDD простым классом
PersonEntity, сложным PersonAggregate или примитивным PersonValueObject, а может
быть абстрагирован до какого-то Agent или User
0 Ответить
DexterHD
31.10.2018 в 15:41

Есть предметная область, в ней есть в ней сущности с отношениями, есть

процессы, есть события — это не DDD
Domain - Предметная область
Entity - Сущность
Associations - Ассоциация
Domain Event - Событие предметной области
Это все понятия из DDD. Не понимаю с чего вы взяли что нет. То что эти же понятия
используются в системном анализе не отменяют того что они используются в DDD. И
там и там у них есть вполне себе конкретное определение о том, что это такое и как
это использовать.
DDD же осуществляет маппинг этих терминов на средства выбранного ЯП, очень
часто ООЯП. И вот тут объективная сущность предметной области субъективно
моделируется разного рода объектами в зависимости от контекста.
Может быть я его не так понял, но по моему книга вообще абстрагирована от ЯП и
рассказывает о том, как подходить к анализу предметной области и как найти общий
язык с заказчиками и всеми участниками процесса, а не о том, как именовать классы и
папки. Domain Model может на выходе вообще превратится в набор отдельно
разрабатываемых и поддерживаемых разными командами приложений, каждое из
которых реализует определенный Bounded Context.
Грубо говоря, если аналитик выделил в предметной области какую-то сущность,
это ещё не значит что в нашей системе она будет представлена как DDD Entity в
«папочке» Domain.

https://habr.com/ru/post/427739/ 26/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Наличие DDD вообще не значит что в коде будут классы «Entity» и папочки «Domain».
Что касается аналитиков, уж извините, предвзято к ним отношусь. Все аналитики из
тех с которыми я встречался почему то никогда ничего не программировали в своей
жизни. Там где они что-то «выделяли», приходилось по итогу идти к заказчику и все за
ними переделывать.
И я сомневаюсь, что Фаулер говорил " entity может являться Агрегатом и собритать
в себе все остальные, в другом просто ValueObject-ом", скорее он говорил «entity
(объективная сущность) может быть представлена ...». Человек (физическое лицо)
— например, это сущность, но он может быть представлен в DDD простым классом
PersonEntity, сложным PersonAggregate или примитивным PersonValueObject, а
может быть абстрагирован до какого-то Agent или User

Да я согласен возможно не совсем точно сформулировал фразу. Это я и имел ввиду.

Может быть представлена. Вот цитата Эванса:
Совокупность взаимосвязанных объектов, которые мы воспринимаем как единое
целое с точки зрения изменения данных, называется АГРЕГАТОМ (AGGREGATE). У
каждо­го АГРЕГАТА есть корневой объект и есть граница. Корневой объект — это
один конкретный объект-сущность (ENTITY), содержащийся в АГРЕГАТЕ.
0 Ответить
VolCh
01.11.2018 в 13:39

Domain — Предметная область

Entity — Сущность
Associations — Ассоциация
Domain Event — Событие предметной области
Это все понятия из DDD. Не понимаю с чего вы взяли что нет. То что эти же
понятия используются в системном анализе не отменяют того что они
используются в DDD. И там и там у них есть вполне себе конкретное определение
о том, что это такое и как это использовать.
Это заимствованные понятия из, скорее всего, бизнес-анализа. Там у них так сказать
общепринятое значение, а в DDD — специальное, вот с той самой точки зрения
изменения данных. И бизнесу язык бизнес-анализа, как ни странно, знаком больше.
книга вообще абстрагирована от ЯП и рассказывает о том, как подходить к
анализу предметной области и как найти общий язык с заказчиками и всеми
участниками процесса
Скорее описано введение в бизнес-анализ, в моделирование бизнес-процессов для
разработчиков и показано как это можно реализовать в коде, на что могут маппиться
https://habr.com/ru/post/427739/ 27/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

понятия бизнес-анализа, как лучше организовать код чтобы избежать множества его
изменений при изменении одного требования, не важно бизнес-логики или UI.
Вот цитата Эванса:
Мыслит он объектами и потоками изменяющихся данных, вот почему ООП —
дефолтная парадигма для применения DDD :)
Но вообще начиналось всё с
Сущность (Entity) вообще ни как не выражается внутри кода. В зависимости от
Ограниченного Контекста (Bounded Context), внутри кода Entity может быть
представлена как простым типом типа ID, так и объектом-значенем (Value Object)
или даже целым Агрегатом (Agregate).
Так вот, сущность бизнес-анализа может выражаться в DDD ООП коде полноценным
объектом, объектом-значением или простым значением. Иногда полноценный
объект ещё и корнем агрегата является или принадлежит отдельному объекту
агрегата.
В этой фразе классическое смешение контекстов :) Сущность предметной области,
если попадает в ограниченный контекст, может выражаться в коде несколькими
видами, в том числе объектом сущности. Обычно если сущность предметной области
в этом контексте изменяется или нужна история изменений, то в коде она
выражается объектом сущности. Этот объект может являться и корнем агрегата, но
это не обязательно — в контексте могут быть одновременно неизменяемые
сущности, а может быть вообще только одна.
0 Ответить

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

ЛУЧШИЕ ЗА СУТКИ ПОХОЖИЕ

ru_vds вчера в 11:00

Апгрейд не нужен, если техника 20 лет работает и не ломается

+84 16K 46 100 +100

https://habr.com/ru/post/427739/ 28/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

dlinyj вчера в 10:01

Реверс-инжиниринг нестандартной ps/2 клавиатуры
Туториал
+64 3.1K 23 14 +14

programmovich вчера в 13:00

Технология ABENICS: революция в области механики?

+52 8.1K 36 51 +51

AndreyKolesnikov вчера в 12:11

Что читать техлиду: 7 увлекательных книг
+47 4.5K 90 5 +5

beskrovnaya вчера в 10:48

Как решать конфликты с уважением к себе и оппонентам? Гайд по
ненасильственному общению
Туториал
+36 2.8K 32 8 +8

Показываем на экране блокировки, когда приедет такси: туториал

по добавлению Live Activity от inDrive
Турбо

МИНУТОЧКУ ВНИМАНИЯ Разместить

https://habr.com/ru/post/427739/ 29/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Итоги 2022 года на Хабре Пушим тему Kubernetes в первом хабрасезоне

Интересно годаСобытие

ВОПРОСЫ И ОТВЕТЫ

Чем отличается контекст от домен в ddd?

Проблемно-ориентированное проектирование · Средний · 2 ответа
Как реализовать карту контекcтов DDD в PHP?
PHP · Простой · 0 ответов
Ограниченные контексты и связи между агрегатами?
Проблемно-ориентированное проектирование · Средний · 1 ответ
Какой практический туториал по ddd посоветуете?
Проектирование программного обеспечения · Простой · 2 ответа
Структура DDD интервью с бизнесом?
Проблемно-ориентированное проектирование · Простой · 1 ответ
Больше вопросов на Хабр Q&A

ЧИТАЮТ СЕЙЧАС

Ваш аккаунт Разделы Информация Услуги

Тестовое задание, выполненное ChatGPT, обмануло рекрутеров и превзошло работы 80%
соискателей

Войти2.5K 4 +4 Публикации Устройство сайта Корпоративный блог

Регистрация Новости Для авторов Медийная реклама
Хабы монитора «Бештау» Для
СМИ показали процесс сборки компаний
M24FHD НативныеЭлектроникс»
на предприятии «Бештау проекты
4.1K 28 +28 Компании Документы Образовательные
Авторы Соглашение программы
Песочница
Апгрейд не нужен, если техника Конфиденциальность
20 лет работает и не ломается Стартапам
16K 100 +100 Мегапроекты

Осторожно: осознанный

21K 160 +160

https://habr.com/ru/post/427739/ 30/31
19/01/2023, 00:36 DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе / Хабр

Настройка языка
Почему стандарты ИСО не публикуют в открытом доступе?

5.4K 31 +31
Техническая поддержка
DevOps-инженерам приготовиться: мы запустили Сезон Kubernetes

Событие Вернуться на старую версию

© 2006–2023, Habr
ИСТОРИИ

Недельный топ Январский Мифы и легенды Маркетплейс Дизайнер Как

годноты от дайджест удалёнки курсов 2.0 на разработал игру в лег
компаний событий для HR в Хабр Карьере Figma Кар
IT

РАБОТА

Cистемный аналитик
533 вакансии

Все вакансии

https://habr.com/ru/post/427739/ 31/31