Домен (или предметная область) — это реальная сфера деятельности бизнеса. Модель — это абстракция, которая упрощённо описывает домен, предметы в нем и их взаимоотношений
На этом строится ключевая идея предметно-ориентированного проектирования (Domain-Driven Design, DDD) - приложение должно быть точной моделью реального бизнеса
Такой подход требует дополнительных ресурсов при проектировании архитектуры, однако полученная архитектура получается понятной для разработчиков, которые знакомы с языком домена, и позволяет бизнес-логике не зависеть от технических деталей и реализации
Для начала нужно обеспечить единый, “вездесущий” язык между разработчиками и бизнес-экспертами
Единый язык представляет из себя описание терминов, концептов и того, как бизнес должен работать
Для того, чтобы создать такой язык, для начала нужно посмотреть, как работать бизнес, определить ключевые бизнес-события, команды и процессы, и задокументировать это, используя диаграммы
Иногда домен разделяют и получают ограниченные контексты - четкие границы, внутри которых у модели и понятий единого языка есть точное значение. Так самолет в контексте продажи имеет смысл модели и количество мест в нем; для техобслуживания - это серийный номер и дата последней проверки
Далее из единого языка выделяют сущности - представления вещей в нашей проблемной области
Например, для того, чтобы сделать карту метро, помогающую составить маршрут, нужны сущности:
Сущность обладает некоторыми свойствами:
Сущности - ключевое понятие в предметно-ориентированном дизайне, но чаще всего на уровне кода разработчики оперируют с объектами со значениеми (Value Object). Они:
Также сущности содержат бизнес-логику. Модель, где бизнес-логика содержится в сервисах, а не сущностях, называется анемичной и считается анти-паттерном
Также выделяют агрегат - группу сущностей и объектов со значениями, которая должна оставаться последовательно при сохранении
Далее идут сервисы - представления бизнес-процессов в предметной области. Сервис представляют поведения сущностей, у них нет внутреннего состояния, и чаще всего они соединяют множество объектов
Для сохранения состояния сущностей используют:
Также используют репозиторий для связи с агрегатом
Далее идет прикладной слой, который включает прикладные сервисы - они координируют управлением, то есть вызывают репозитории, запускают доменные сервисы, управляют транзакциями
За ним идет инфраструктурный слой. Инфраструктурные сервисы не содержат бизнес-логики, а только базовые инструменты для поддержания инфраструктуры (например, сервис для отправки сообщения по электронной почте)