Comments 14
Полная цитата:
Use Case не могут вызывать друг-друга.
При взгляде на код сценария мы должны видеть все его шаги.
Никто не запрещает выносить общий код в службы(service).
Речь идет о системе по модели запрос-ответ.
Интерактор — нечто, что обрабатывает некое событие.
Например, запрос пользователя или сообщение от сторонней системы.
В этом контесте интеракторы не общаются между собой напрямую.
Естественно, что пользователь может передать данные от одного интерактора другому.
Да, итеракторы не вызавают друг-друга, но могут разделять логику через сервисы.
Пишу это конечно не ради того, чтобы поспорить, а скорее поделиться своим видением. Вот «горячий» пример из моей практики: данные через входной шлюз поступают на слой сценариев, проходят сквозь «каналы и фильтры» и выходят через выходной шлюз. Это конечно не запрос-ответ, но хорошо иллюстрирует, что на слое сценариев логика задействует далеко не одну сущность.
В любом случае спасибо за книгу и желание поделиться своим опытом.
Конечно, интерактор может использовать несколько Сущностей, Служб.
Может не совсем удачная, но аналогия.
Интерактор — это как целая программа, бинарник. Она, как и другие, может использовать разделяемые библиотки. Пользователь может объединять их с момощью перенаправления потоков ввода-вывода.
Если остались вопросы, то лучше уже в личку.
Например ничего не сказано про анемичную модель домена (Anemic Domain Model). Мартин Фаулер и некоторые другие эксперты считают такую модель анти-паттерном, который на корню убивает все преимущества ООП. (Предлагается рассматривать, бизнес-модель не как класс с сеттерами и геттерами, а как набор классов, функций и т.д. тесно взаимодействующих друг с другом. В данной модели важно в первую очередь поведение а не данные).
Так же не совсем раскрыта тема ограниченных контекстов, а это очень важная тема.
Ее понимание ключ к знанию о том, где можно скопировать данные и создать новый объект/класс/значение, а где дублирование кода — явное зло.
Если быть конкретнее, Сущность (Entity) вообще ни как не выражается внутри кода. В зависимости от Ограниченного Контекста (Bounded Context), внутри кода Entity может быть представлена как простым типом типа ID, так и объектом-значенем (Value Object) или даже целым Агрегатом (Agregate).
Например в одном контексте сущность Consumer может быть агрегатом Consumer с кучей бизнес-логики, а в другом контексте всего лишь полем consumer_id, или value-object-ом Consumer хранящим только несколько интересующих нас полей.
Если выражаться языком 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 говорил именно так.
Есть предметная область, в ней есть в ней сущности с отношениями, есть процессы, есть события — это не 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 ООП коде полноценным объектом, объектом-значением или простым значением. Иногда полноценный объект ещё и корнем агрегата является или принадлежит отдельному объекту агрегата.
В этой фразе классическое смешение контекстов :) Сущность предметной области, если попадает в ограниченный контекст, может выражаться в коде несколькими видами, в том числе объектом сущности. Обычно если сущность предметной области в этом контексте изменяется или нужна история изменений, то в коде она выражается объектом сущности. Этот объект может являться и корнем агрегата, но это не обязательно — в контексте могут быть одновременно неизменяемые сущности, а может быть вообще только одна.
DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе