>> Какие существуют паттерны в DDD? 🧐 Действительно важный вопрос для тех, кто только входит в тему. Потому что без паттернов непонятно как получать __повторяемый результат__ и __переносимый опыт__. В DDD все паттерны делятся на стратегические и тактические. Стратегические фокусируются на __высокоуровневой организации системы и определяют границы между различными частями домена__: ▪️Ubiquitous Language – общая терминология для разработчиков и бизнес-экспертов ▪️Core Domain, Supporting Domain, Generic Domain – классификация поддоменов по важности для бизнеса ▪️Bounded Context – четко определенные границы, в которых применяется конкретная модель домена ▪️Context Map – визуализация отношений между ограниченными контекстами В свою очередь __связи между ограниченными контекстами – это тоже своего рода паттерны__. Чтобы не нагромождать, напишу о них отдельно, к тому же есть и такой вопрос. Тактические шаблоны применяются внутри одного ограниченного контекста для реализации бизнес-логики: ▪️Entity (сущность) – объект с уникальной идентификатором, сохраняющейся во времени ▪️Value Object – неизменяемый объект без идентификатора ▪️Aggregate – кластер связанных объектов (value objects + entities), обрабатываемых как единое целое, с корневой сущностью (Aggregate Root) ▪️Domain Service – операции, не принадлежащие конкретной сущности (а не «микросервис», как некоторые думают =) ) ▪️Repository – абстракция для доступа к данным ▪️Domain Event – значимое изменение состояния в домене ▪️Factory – создание сложных объектов Архитектурные паттерны, часто используемые с DDD: ▪️Layered Architecture – разделение на слои: presentation, application, domain, infrastructure ▪️Hexagonal Architecture – изоляция бизнес-логики от технических деталей ▪️CQRS – разделение операций чтения и записи ▪️Event Sourcing – сохранение изменений состояния как последовательности событий То есть DDD достаточно богат на паттерны. И они связаны друг с другом. Например, без исследования предметной области как таковой не определить границы применимости модели (Bounded Context) ну просто потому, что – а в чем вы будете границы проводить? Микросервисы сделали очень популярным паттерн Bounded Context, сотни тысяч статей, жаль, что в большинстве из них не указывается, что вообще-то сначала нужно построить модель домена, провести классификацию (найти Core Domains), а потом уже в них под конкретное решение проблем провоить границы. #dddbasics ✅