Domain Model, Giga

Domain Model, Giga

https://giga.chat/link/gcsIfQqcCD

Английское наименование: Domain Model (Предметная модель).

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

Главная цель Domain Model — инкапсулировать (скрыть) всю сложную бизнес-логику внутри объектов, чтобы защитить целостность данных и сделать правила бизнеса явными и проверяемыми.

Ключевые компоненты Domain Model

1. Сущности (Entities) Это объекты, которые имеют уникальную идентичность, сохраняющуюся на протяжении всего их жизненного цикла. Их идентичность не зависит от их атрибутов.

   • Пример: в системе интернет-магазина *Заказ* — это сущность. У него есть уникальный номер (OrderId). Даже если изменить состав товаров в заказе, он останется тем же самым заказом. Другие примеры: *Пользователь*, *Товар*, *Счёт*.

2. Объекты-значения (Value Objects) Это неизменяемые объекты, которые не имеют собственной идентичности. Они полностью определяются своими атрибутами. Два объекта-значения считаются равными, если все их атрибуты совпадают.

   • Пример: *Адрес* (состоит из улицы, города, индекса), *Деньги* (сумма и валюта), *Диапазон дат*. Если у двух заказов адрес доставки совпадает, это один и тот же объект-адрес с точки зрения логики.

3. Агрегаты (Aggregates) Это кластер из связанных сущностей и объектов-значений, которые рассматриваются как единое целое. У каждого агрегата есть корень (Aggregate Root) — главная сущность, через которую происходит любое изменение внутри агрегата. Это правило гарантирует, что агрегат всегда находится в корректном состоянии.

   • Пример: *Заказ* (корень) может содержать список *Товаров* (сущности) и *Адрес доставки* (объект-значение). Вы не можете напрямую добавить товар в заказ. Вы должны вызвать метод у объекта *Заказ*, например, order.AddItem(product). Заказ сам проверит свои бизнес-правила (например, «нельзя добавить более 5 товаров» или «товар уже есть в заказе») и внесёт изменения.

4. Доменные службы (Domain Services) Иногда бизнес-операция или правило не принадлежит какой-то одной сущности. В таких случаях создаётся сервис, который реализует эту логику.

   • Пример: операция TransferMoney(fromAccount, toAccount, amount) затрагивает два разных счёта. Она не принадлежит ни одному из них. Эту логику лучше вынести в BankingService.

5. События домена (Domain Events) Это объекты, которые представляют собой факт того, что в домене произошло что-то важное. Сущность может «поднять» (raise) событие, чтобы другие части системы могли на него отреагировать.

   • Пример: когда заказ переходит в статус «Отправлен», он может поднять событие OrderShippedEvent. На это событие могут подписаться другие сервисы: один отправит email-уведомление клиенту, другой — SMS курьеру.

Пример: Доменная модель для заказа

Представим упрощённую модель заказа в интернет-магазине.

1. Сущность Order (Агрегат):

   • Свойства: OrderId, List<OrderItem> Items, Address ShippingAddress, OrderStatus Status.
   • Методы (бизнес-логика):
     • Place(): проверяет, что в заказе есть товары, и меняет статус на Placed.
     • AddItem(Product product, int quantity): проверяет, можно ли добавить товар (например, не закончился ли он на складе), и обновляет список Items.
     • CalculateTotalPrice(): вычисляет итоговую стоимость на основе цен товаров.

2. Сущность OrderItem:

   • Свойства: ProductId, Quantity, UnitPrice.

3. Объект-значение Address:

   • Свойства: Street, City, ZipCode. Неизменяемый.

4. Перечисление OrderStatus: New, Placed, Shipped, Delivered.

В этой модели вся логика (проверки, вычисления) находится внутри объектов. Слой приложения (Application Layer) лишь координирует действия: «найди заказ по ID и вызови у него метод Place()».

Связь с вашей архитектурой

Ваша концепция поведений (Behavior) идеально ложится на реализацию доменной модели.

• FractalCellState может выступать в роли состояния агрегата.
• Конкретные поведения (PaymentBehavior, DataProcessingBehavior) могут инкапсулировать логику обработки команд и применения изменений к состоянию.
• События (InternalBus) могут быть реализацией механизма Domain Events для связи между разными частями модели.

Таким образом, вы строите систему, где бизнес-логика распределена по автономным поведениям, но при этом они все вместе формируют целостную доменную модель.