Реклама
Комментарии 14
В своей книге на странице про чистую архитектуру вы написали: Use Case не могут вызывать друг-друга. Что вы под этим подразумеваете? Интеракторы не могут общаться между собой?

Полная цитата:


Use Case не могут вызывать друг-друга.
При взгляде на код сценария мы должны видеть все его шаги.
Никто не запрещает выносить общий код в службы(service).

Речь идет о системе по модели запрос-ответ.
Интерактор — нечто, что обрабатывает некое событие.
Например, запрос пользователя или сообщение от сторонней системы.


В этом контесте интеракторы не общаются между собой напрямую.
Естественно, что пользователь может передать данные от одного интерактора другому.
Да, итеракторы не вызавают друг-друга, но могут разделять логику через сервисы.

Я считаю, что в пределах слоя все сущности могут совершенно спокойно общаться между собой, если же нет, то по сути вы этот слой разбиваете на кучу слоёв, которые между собой должны общаться согласно общих правил чистой архитектуры. Если же обсуждать именно запрос-ответ, то тогда кого спросили, тот и ответил, а всё остальное «общение» интерактора инкапсулировано (не видно).

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

В любом случае спасибо за книгу и желание поделиться своим опытом.

Конечно, интерактор может использовать несколько Сущностей, Служб.


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


Если остались вопросы, то лучше уже в личку.

Как по мне, то общения программных сущностей (в широком смысле слова) на одном слое стоит избегать за исключением доменного слоя. Общую логику или выносить на слои ниже, или на слое выше создавать какой-то оркестратор или координатор.
В целом перевод хороший. В начале вообще супер, под конец немного путано на мой взгляд. Автором (без претензий к переводчику) на мой взгляд упущены некоторые важные концепции.

Например ничего не сказано про анемичную модель домена (Anemic Domain Model). Мартин Фаулер и некоторые другие эксперты считают такую модель анти-паттерном, который на корню убивает все преимущества ООП. (Предлагается рассматривать, бизнес-модель не как класс с сеттерами и геттерами, а как набор классов, функций и т.д. тесно взаимодействующих друг с другом. В данной модели важно в первую очередь поведение а не данные).

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

Если быть конкретнее, Сущность (Entity) вообще ни как не выражается внутри кода. В зависимости от Ограниченного Контекста (Bounded Context), внутри кода Entity может быть представлена как простым типом типа ID, так и объектом-значенем (Value Object) или даже целым Агрегатом (Agregate).

Например в одном контексте сущность Consumer может быть агрегатом Consumer с кучей бизнес-логики, а в другом контексте всего лишь полем consumer_id, или value-object-ом Consumer хранящим только несколько интересующих нас полей.
> Если быть конкретнее, Сущность (Entity) вообще ни как не выражается внутри кода.

Если выражаться языком DDD и ООП, то Entity DDD представляется обычно объектом со сложным поведением, возможно агрегирующим другие Entity. ValueObject или просто значения не представляют Entity.

Другое дело, что сущность предметной области (не путать с Entity в DDD) в одном Bounded Context может представляться Entity, а в другом ValueObject, при этом ValueObject может иметь ссылку на Entity из другого Bounded Context, а может не иметь.
объектом со сложным поведением,

Я интерпретирую знания о DDD немного по другому. Но это все вопрос исключительно как раз «единого языка» и правильности перевода и интерпретации. В моем понимании, объект со сложным поведением (а точнее набор этих объектов) называется «Модель Предметной Области». Эта модель может состоять не из одного класса, но там будут и классы отражающие саму сущность и объекты-значения и вспомогательные классы и константы и т.п.

возможно агрегирующим другие Entity. ValueObject или просто значения не представляют Entity.

Это в моей картине мира называется Агрегат.

Другое дело, что сущность предметной области (не путать с Entity в DDD)

Предметная область — это буквально Domain. Entity — сущность предметной области. Это все из DDD, что значит не путать с DDD? Если вы о чем то еще, не о DDD то о чем? Я если честно тут вас не понял.

в одном Bounded Context может представляться Entity, а в другом ValueObject, при этом ValueObject может иметь ссылку на Entity из другого Bounded Context, а может не иметь.

Я и говорю, в одном Bounded Context entity может являться Агрегатом и собритать в себе все остальные, в другом просто ValueObject-ом, который в себе будет хранит ссылку на сущность.

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

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


DDD же осуществляет маппинг этих терминов на средства выбранного ЯП, очень часто ООЯП. И вот тут объективная сущность предметной области субъективно моделируется разного рода объектами в зависимости от контекста. И объективная сущность может моделироваться в ООЯП как DDD Entity а может как DDD ValueObject, а может как скалярное значение. DDD частично позаимствовала термины из анализа, но однозначного соответствия нет. Грубо говоря, если аналитик выделил в предметной области какую-то сущность, это ещё не значит что в нашей системе она будет представлена как DDD Entity в "папочке" Domain.


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

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

Domain - Предметная область
Entity - Сущность
Associations - Ассоциация
Domain Event - Событие предметной области

Это все понятия из DDD. Не понимаю с чего вы взяли что нет. То что эти же понятия используются в системном анализе не отменяют того что они используются в DDD. И там и там у них есть вполне себе конкретное определение о том, что это такое и как это использовать.

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

Может быть я его не так понял, но по моему книга вообще абстрагирована от ЯП и рассказывает о том, как подходить к анализу предметной области и как найти общий язык с заказчиками и всеми участниками процесса, а не о том, как именовать классы и папки. Domain Model может на выходе вообще превратится в набор отдельно разрабатываемых и поддерживаемых разными командами приложений, каждое из которых реализует определенный Bounded Context.

Грубо говоря, если аналитик выделил в предметной области какую-то сущность, это ещё не значит что в нашей системе она будет представлена как DDD Entity в «папочке» Domain.

Наличие DDD вообще не значит что в коде будут классы «Entity» и папочки «Domain». Что касается аналитиков, уж извините, предвзято к ним отношусь. Все аналитики из тех с которыми я встречался почему то никогда ничего не программировали в своей жизни. Там где они что-то «выделяли», приходилось по итогу идти к заказчику и все за ними переделывать.

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


Да я согласен возможно не совсем точно сформулировал фразу. Это я и имел ввиду. Может быть представлена. Вот цитата Эванса:
Совокупность взаимосвязанных объектов, которые мы воспринимаем как единое целое с точки зрения изменения данных, называется АГРЕГАТОМ (AGGREGATE). У каждо­ го АГРЕГАТА есть корневой объект и есть граница. Корневой объект — это один конкретный объект-сущность (ENTITY), содержащийся в АГРЕГАТЕ.
Domain — Предметная область
Entity — Сущность
Associations — Ассоциация
Domain Event — Событие предметной области
Это все понятия из DDD. Не понимаю с чего вы взяли что нет. То что эти же понятия используются в системном анализе не отменяют того что они используются в DDD. И там и там у них есть вполне себе конкретное определение о том, что это такое и как это использовать.

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


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

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


Вот цитата Эванса:

Мыслит он объектами и потоками изменяющихся данных, вот почему ООП — дефолтная парадигма для применения DDD :)


Но вообще начиналось всё с


Сущность (Entity) вообще ни как не выражается внутри кода. В зависимости от Ограниченного Контекста (Bounded Context), внутри кода Entity может быть представлена как простым типом типа ID, так и объектом-значенем (Value Object) или даже целым Агрегатом (Agregate).

Так вот, сущность бизнес-анализа может выражаться в DDD ООП коде полноценным объектом, объектом-значением или простым значением. Иногда полноценный объект ещё и корнем агрегата является или принадлежит отдельному объекту агрегата.


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

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