В прошлом посте мы разбирали Transactional Script - отличный инструмент для старта. Но любой проект развивается. Со временем вы начинаете замечать, что Transactional Script становится сильно усложненным. В них добавляются простые бизнес-инварианты, дополнительные проверки и сами структуры данных становятся довольно сложными.
Скрипт перестает быть читабельным, занимает несколько экранов, а логика начинает дублироваться. Кажется, что самое время достать "тяжелую артиллерию" из Domain Driven Design - паттерн Domain Model.
Но подождите начинать тратить ресурсы и время на проектирование архитектуры с Аггрегатами. Если ваша система относится не к главному бизнес-домену (Core Domain), а к вспомогательному (Supporting Domain) или общему (Generic Domain), а бизнес-процесс все еще не такой сложный, то идеальным решением становится паттерн Active Record.
Что из себя представляет Active Record
Паттерн был описан Мартином Фаулером в его книге Patterns of Enterprise Application Architecture (2002) и популяризирован такими фреймворками, как Ruby on Rails.
Его суть проста: объект содержит и данные (строку в базе данных), и поведение, и логику для сохранения самого себя в базу.
В отличие от анемичных моделей в Transactional Script, объекты Active Record обладают не только данными. Они знают как себя проверять, как изменять свое состояние, как сохранять и восстанавливать свое состояние.
Пример кода в моем телеграм-канале
Active Record как промежуточный шаг к Domain Model
Active Record — отличный промежуточный этап эволюции:
- Начинаете с Transactional Script.
- Добавляете поведение в сущности → Active Record.
- Когда правил становится слишком много, инварианты критичны и появляются value objects - начинаете выносить логику из сущности в агрегаты -> Domain Model.
Как не усложнить работу с Active Record и почему стоит делегировать управление состоянием объекта другому объекту, будет в следующем посте.
#DomainDrivenDesign #DDD #systemdesign #SoftwareArchitecture