Доменные модели бизнес сущностей

В DDD, область применения доменной модели называется изолированным контекстом (Bounded context). Изолированный контекст включает в себя код, который реализует модель.

При использовании микросервисной архитектуры изолированный контекст соответствует одному или нескольким сервисам.

Структура и иерархия	Описание
Компания	Пример: например Амазон
— domain	Пример: интернет магазин Амазон
— domain	Пример: облачные вычисления Амазон
— — subdomain	Достаточно масштабная бизнес-обязанность (bounded context), например: бухгалтерия, доставка и т.п. Например для бухгалтерии мы используем «1С Бухгалтерия» в рамках которого есть единый Ubiquitous language.
— — — core	Основные вещи (то, без чего subdomain не имеет смысла), то, без чего субдомен не состоится
— — — supporting	Второстепенные внутренние вещи, например: формирование заказа, маркетинг
— — — generic	Второстепенные внешние вещи — то, что может быть отдано на аутсорс, например оплата через Paypal
— — — — aggregate	Агрегат — некая бизнес-сущность, которая состоит из других бизнес-объектов
— — — — — entity	Сущность — бизнес объект имеющий уникальный ID/GUID, содержит небольшой набор критических бизнес-правил, оперирующих критическими бизнес-данными. Объект-сущность или содержит критические бизнес-правила в себе, или имеет простой доступ к ним (например: банк взимает XX% за кредит). Интерфейс сущности состоит из функций, реализующих критические бизнес-правила и оперирующих этими данными. Критические правила и критические данные неразрывно связаны друг с другом, поэтому являются отличными кандидатами на объединение в объект (название предложил Ивар Якобсон).
— — — — — — value object	Объект значение — бизнес объект не имеющий уникального идентификатора. Два объекта value с одинаковыми значениями атрибутов считаются равными.

НЕ ООП ЕДИНЫ! Domain Driven Design на примере ХОЛОДИЛЬНИКА / Tech Lead Борис Беньковский

Варианты использования

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

Бизнес-правила

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

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

Domain Models: Anemic vs Rich

Поддомены VS сервисы

Рассмотрим пример домена компании FTGO:

В книге Domain Driven Design, Eric Evans создает классификацию различных типов объектов предметной области, и давайте посмотрим про отличие анемичной доменной модели от модели агрегата:

Мартин Фаулер говорит так: логика домена (domain logic) имеет дело только с предметной областью как таковой (примером могут служить стратегии вычисления зачтенного дохода по контракту), а логика приложения (application logic) описывает сферу ответственности приложения (скажем, уведомляет пользователей и сторонние приложения о протекании процесса вычисления доходов).

Альтернативой является — table driven design (Active record, которая отражает суть предметной области).

Тактические паттерны

При реализации любого из видов моделей часто используют паттерны:

separated interface — интерфейс модели, который должен быть в доменном слое, а реализация в инфраструктурном слое (чтобы избавить доменную логику от сторонних зависимостей).
отложенные эвенты — события которые срабатывают, когда транзакция закомичена, но не раньше.

Источник: yapro.ru

Domain Model – Domain Logic Patterns (PoEAA)

Модель предметной области (Domain Model) – объектно-ориентированный шаблон проектирования. Цель проектирования предметной области – определение бизнес-объектов, которые представляют реальные сущности предметной области. При использовании модели предметной области бизнес-сущности и сущности предметной области включают и поведение, и структуру.

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

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

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