Что такое Domain-Driven Design (DDD)

Ну слушай, вот есть у тебя проект, а в нём какая-нибудь ебанутая бизнес-логика, как у банка или страховой. Там не просто кнопочку нажать — там правила на правилах, исключения на исключениях. Так вот, Domain-Driven Design — это такой подход, чтобы не сойти с ума, пытаясь эту всю хуйню в код запихнуть. Суть в том, чтобы твоя программа говорила на том же языке, что и твои заказчики-эксперты, эти, блядь, бизнес-аналитики.

Основные фишки, без которых нихуя не понятно:

1. Единый язык (Ubiquitous Language):

   • Это когда вы с экспертами и между собой договариваетесь, что «клиент» — это вот это, «заявка» — это вот так, а «просрочка» — это вот эта хуйня. И этот же самый язык ты потом пишешь в коде. Чтобы не было такого, что ты говоришь «юзер», а он имеет в виду «аккаунт», и вы оба думаете, что поняли друг друга, а на деле — пиздец и два дня дебага.

2. Ограниченный контекст (Bounded Context):

   • Это, блядь, самое важное. Один и тот же термин в разных отделах — это разные сущности. Вот смотри: «Товар» для отдела продаж — это картинка, название и цена, чтобы быстрее впарить. А «Товар» для склада — это габариты, вес и температура хранения, чтобы он не сгнил. Это два РАЗНЫХ контекста! И пытаться слепить из них одну универсальную хуйню на все случаи жизни — это прямой путь в ад. Делай две разные модели и не мучайся.

3. Агрегат и Корень агрегата (Aggregate & Aggregate Root):

   • Представь, что у тебя есть «Заказ». В нём есть сам заказ, список позиций, платёжка, доставка. Так вот, Агрегат — это весь этот кластер связанной хуеты, которую ты изменяешь как единое целое. А Корень — это главная сущность, через которую идёт всё общение с внешним миром. Не лезь ты внутрь агрегата и не пытайся поменять позицию заказа напрямую! Только через методы корня. Он там свои инварианты (бизнес-правила, блядь) проверит.

     // Вот он, Корень агрегата. Царь и бог.
     public class Order : AggregateRoot
     {
     public Guid Id { get; private set; }
     private List<OrderLine> _lines = new(); // Список позиций — внутри, приватный.
     
     // Хочешь добавить позицию? Делай только так!
     public void AddItem(Product product, int quantity)
     {
         // А вот и бизнес-правило: в отменённый заказ хуй что добавишь.
         if (Status == OrderStatus.Cancelled)
             throw new DomainException("Иди нахуй, заказ отменён!");
     
         _lines.Add(new OrderLine(product.Id, quantity));
     }
     // Больше никто не может _lines тронуть. Красота.
     }

4. Репозиторий (Repository):

   • Это такая прослойка, которая делает вид, что твои агрегаты живут в какой-то волшебной коллекции в памяти. Хочешь заказ? orderRepository.Get(id). Сохранить? orderRepository.Save(order). А то, что там внутри база данных, кэш или файл на диске — это твои личные проблемы. Репозиторий работает только с Корнями агрегатов, запомни это.

5. Доменное событие (Domain Event):

   • Это когда в домене происходит что-то важное, о чём должны узнать другие. Заказ создан? Вызывай событие OrderCreatedEvent. И пусть другие модули (например, служба нотификаций или склад) на него подписываются и делают что надо. Главное — не превращать это в спагетти-код, где всё зависит от всего.

6. Архитектура:

   • Всё это безобразие обычно раскладывают по слоям. Доменный слой — это святое. Только бизнес-логика, ни одной ссылки на базу данных, HTTP или прочую инфраструктуру. Слой приложения — тут уже координация, вызов репозиториев. Инфраструктурный слой — тут уже все эти грязные подробности работы с внешним миром.

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

Когда НЕ надо? Ну, если ты делаешь простенький бложик или прототип на неделю. Не обвешивай простую CRUD-форму по учёту котиков этим всем пафосом. Получится как с танком на дачу — мощно, но дохуя сложно и бензина жрёт как не в себя.