Для себя хочу иметь заметку про DDD в которой кратко будет все что нужно занать про DDD. "кратко" - это, скорее всего, не возможно в формате заметки или даже целой статьи... Но почему бы и не попробовать.

Domain-Driven Design: Everything You Always Wanted to Know About it, But Were Afraid to Ask

Агрегаты

Domain-driven design: рецепт для прагматика

DDD: Strategic Design: Core, Supporting, and Generic Subdomains

Как приручить DDD. Часть 1. Стратегическая

Как приручить DDD. Часть 2. Практическая

Что такое DDD ?

Много разных определений на все вкусы:

Domain-Driven Design - это борьба со сложностью бизнес-процессов и их автоматизации и реализации в коде

Domain-Driven Design - это единый язык между экспертами и программистами

Domain-Driven Design - это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

Domain-Driven Design - is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.

Domain-Driven Design - is an approach to software design that glues the system’s implementation to a constantly evolving model, leaving aside irrelevant details like programming languages, infrastructure technologies, etc…

Как это работает?

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

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

Немного деталей как устроено DDD

• Domain / Домен - глобальная предметная область

• Subdomain / Поддомен - бизнес задача, обладают высокой связностью

  • Core - конкурентное преимущество компании

  • Supporting - не является уникальных знанием компании но без этого все еще нельзя существовать

  • Generic - типовые задачи которые могут быть делегированы третьим лицам, компании

  • Bounded context / Границ поддомена - это ограниченная часть системы, в которой мы реализуем нашу бизнес-логику

• Entity / Сушность - объект у которого есть уникальный идентификатор. Например: покупатель, заказ.

• Value Object / Объект-значение - объект который описывает характеристики. это атрибуты и они могут быть частью нескольких Entity. Например: адрес.

• Aggregates / Агрегаты - это кластер сущностей и объектов-значений, объединённых общими инвариантами. Любое взаимодействие с агрегатом осуществляется через одну и только одну из его сущностей, называемую корнем агрегата.

DDD и микросервисы

Паттерны

PDF, PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN

Особенности и проблемы DDD

• Хорошо подходит для редкоменяющихся, налаженных бизнес-процессов

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

• Плохо масштабируется

Книги

Вон Вернон: Реализация методов предметно-ориентированного проектирования PDF, Implementing Domain-Driven Design

Эрик Эванс: Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем PDF, Domain -Driven Design TACKLING COMPLEXITY IN ТНЕ HEART OFSOFTWARE

книги по ссылкам здесь

Modern Software Architecture: Domain Driven Design