Репозитории, фабрики и доменные сервисы
Репозитории, фабрики и доменные сервисы являются фундаментальными строительными блоками стратегического проектирования в Domain-Driven Design. Они помогают отделить логику предметной области от инфраструктуры, обеспечить устойчивые границы контекстов и поддержать эволюцию моделей при сохранении инвариантов домена. В этой главе рассматриваются принципы построения репозиториев и фабрик, роль доменных сервисов, а также связь этих концепций с интеграционными контрактами и управлением изменениями междуBounded Contexts.
Краткое введение
В контексте DDD репозитории выступают как абстракции доступа к состоянию агрегатов и их жизненному циклу, позволяя доменной модели оставаться persistence-ignorant и сохранять чистоту предметной области. Фабрики отвечают за создание сложных агрегатов и за соблюдение их инвариантов на входе. Доменные сервисы применяются для операций, которые не естественны для инкапсуляции внутри одного агрегата или требуют координации между несколькими агрегатами. Вместе эти паттерны формируют устойчивый механизм эволюции моделей, поддерживаемый интеграционными контрактами и строгими правилами изменения инфраструктурного слоя.
- Роли и границы репозиториев в рамках агрегатов и Bound Context.
- Фабрики как средство сохранения инвариантов при создании сложных агрегатов.
- Доменные сервисы для координации операций, выходящих за рамки одного агрегата.
- Интеграционные контракты, evolve-пути моделей и эволюция архитектуры между контекстами.
- Практики тестирования, миграций и управления изменениями.
Введение: контекст и принципы
В DDD репозиторий не является просто способом чтения и записи объектов. Это контракт границы между доменной моделью и инфраструктурой. Репозитории должны обеспечивать доступ к агрегатам по идентификатору и поддерживать консистентное состояние модели на границе контекста. При этом они не должны проникать в бизнес-логику и не должны заменять ее. ВнутриBounded Context репозитории позволяют реализовать единый паттерн доступа к данным без привязки к конкретному механизмy хранения.
Фабрика представляет собой средство создания агрегатов так, чтобы на входе соблюдались все бизнес-инварианты. В отсутствие фабрики конструктор агрегата может быть перегружен множеством параметров, что затрудняет поддержку корректности и тестируемость. Фабрика централизует знания об инвариантах и обеспечивает единый путь создания валидного состояния.
Доменные сервисы применяются тогда, когда операция не должна жить в рамках одного агрегата, или ее реализация требует координации между несколькими агрегатами или внешними системами. Доменные сервисы остаются частью доменной модели и участвуют в согласовании бизнес-правил, но не владеют состоянием в рамках конкретного агрегата.
Репозитории: границы, контракт и реализация
Репозитории служат абстракциями над хранилищем, которые позволяют доменной модели фокусироваться на бизнес-логике, а не на деталях сохранения. В рамках DDD репозитории следует проектировать под каждый агрегат и, как правило, на уровне каждого Bound Context. Вложенная концепция Unit of Work обеспечивает атомарность транзакций на границе контекста и может координировать операции над несколькими репозиториями в рамках одной бизнес-операции.
Основные принципы:
-
Репозиторий привязан к агрегату (Aggregate Root) и обеспечивает поиск по идентификатору, добавление и удаление, а также сохранение изменений через единый механизм.
-
Реализация репозитория должна быть инфраструктурной: в доменной части держится интерфейс и контракт, а конкретные реализации находятся в слое инфраструктуры.
-
Репозитории должны быть доступны через интерфейсы, поддерживая тестируемость и заменяемость инфраструктуры без изменений доменной логики.
-
Изменение структуры хранилища не должно приводить к непосредственным изменениям в доменной модели; репозитории должны скрывать детали persistence.
public interface IRepository<T, in TKey> where T : IAggregateRoot { Task<T> GetByIdAsync(TKey id); Task AddAsync(T aggregate); Task UpdateAsync(T aggregate); Task DeleteAsync(T aggregate); }В контексте архитектуры часто выделяют паттерн Unit of Work, который агрегирует изменения, сделанные несколькими репозиториями, и фиксирует их как единую транзакцию. В рамках Bound Context это позволяет сохранить консистентность состояния агрегатов, не рассылая каждую операцию по разным слоям:
-
Все изменения в рамках одного бизнес-процесса агрегаются в рамках одной транзакции.
-
Репозитории работают через единый контекст сохранения данных.
-
В случае кросс- контекстной коммуникации применяются Anti-Corruption Layer и интеграционные контракты.
Репозитории часто реализуют подход "потребитель-подписчик" к изменению состояния. В этом случае чтение может быть ленивым, а сохранение - моментальным, что соответствует моделям консистентности в рамках контекста и требованиям к латентности. Важным аспектом является тестируемость: репозитории должны позволять подмену реализаций для тестирования бизнес-логики без обращения к реальному хранилищу.
Интеграция с Bound Context и внешними сервисами требует аккуратной координации: репозитории работают внутри контекста, а межконтекстная коммуникация чаще реализуется через доменные события или интеграционные контракты. В этом ключе репозиторий сосуществует с фабрикой и доменными сервисами как часть единой архитектурной единицы.
Фабрики: создание агрегатов и инварианты
Фабрика служит единым входом для создания новых агрегатов. Она обеспечивает согласованность invariants на старте и скрывает сложность формирования начального состояния, которое может включать вложенные сущности, параметры валидации и зависимые объекты. В рамках Domain-Driven Design фабрика предотвращает "разрывы" при создании агрегатов и упрощает тестирование.
Ключевые принципы:
- Фабрика должна иметь приватные конструкторы и статические методы создания (factory methods) или отдельный фабричный класс.
- Инварианты агрегата должны соблюдаться сразу после создания; фабрика выполняет проверки и возвращает валидный объект.
- Фабрика может строить как новые агрегаты, так и восстанавливать их из данных хранения (rehydration), но это не должно нарушать принципа сохранения бизнес-логики внутри модели.
public static class OrderFactory { public static Order CreateNew(string customerId, IReadOnlyListlines) { if (string.IsNullOrWhiteSpace(customerId)) throw new DomainException("Customer is required"); if (lines == null || lines.Count == 0) throw new DomainException("At least one line is required"); var order = new Order(customerId); foreach (var draft in lines) { order.AddLine(draft.ProductId, draft.Quantity, draft.Price); } order.ValidateInvariants(); return order; } } Важно помнить: конструкторы агрегатов должны быть ограничеными снаружи. Приватные конструкторы или внутренние фабричные методы требуют явной точки входа для создания валидного состояния. Это обеспечивает единый путь и упрощает рефакторинг бизнес-логики без расхождений в местах создания объектов.
Фабрика может использоваться как механизм диспетчеризации сложных сценариев, когда создание агрегата зависит от внешних условий, материалов или статусов. В таких случаях фабрика может вернуться к состоянию «не создано» до тех пор, пока не будут удовлетворены все зависимости. Это облегчает тестирование и внедрение новых сценариев создания без изменения клиентского кода, который требует готовый агрегат.
С точки зрения эволюции архитектуры фабрики интегрируются с изменениями в доменной модели: добавление новых полей, изменение инвариантов или переход к новым векторам поведения требует обновления фабрик без затрагивания клиентской логики. В рамках Bound Context фабрики помогают сохранить контракт создания и упрощают миграцию при изменении бизнес-правил.
Доменные сервисы: координация и операции вне агрегатов
Доменные сервисы реализуют бизнес-правила и операции, которые выходят за рамки одного агрегата или нуждаются в координации между несколькими агрегатами. Они помогают сохранить чистоту сущностей и агрегаций, избегая чрезмерной сложности внутри них, когда бизнес-логика требует взаимодействия на уровне сервиса.
Когда применять доменные сервисы:
- Операции, которые затрагивают несколько агрегатов, но не являются частью одного из них.
- Логика, не тесно связанная с состоянием сущности в рамках конкретного агрегата.
- Координация процессов через доменные события и взаимодействие с инфраструктурой при сохранении инвариантов домена.
Доменные сервисы должны быть в контексте бизнес-правил, а не реализацией технической инфраструктуры. Они часто работают через репозитории, чтобы извлекать и сохранять агрегаты, а также через доменные события для оповещения других частей системы о произошедших изменениях.
public class PricingService : IDomainService
{
public Money CalculateDiscount(Order order)
{
var total = order.GetTotal();
if (total.Amount > 1000) return new Money(50, total.Currency);
if (order.CustomerStatus == CustomerStatus.Premium) return new Money(0, total.Currency);
return new Money(0, total.Currency);
}
}
Доменные сервисы должны быть тестируемыми и детерминированными. Они не удерживают состояние между вызовами; они являются выразителями бизнес-правил и координаторами, используя состояние агрегатов как входные данные. Взаимодействие доменных сервисов с репозиториями и фабриками обеспечивает возможность комплексной, но управляемой эволюции доменной модели. При необходимости доменные сервисы могут публиковать события, которые потом обрабатываются другими компонентами системы, реализующими интеграцию между Bound Contexts.
Интеграционные контракты и эволюция моделей
Репозитории, фабрики и доменные сервисы функционируют внутриBounded Context, но бизнес-реалии часто требуют взаимодействий между контекстами. Интеграционные контракты задают соглашения по данным и протоколам обмена между системами и контекстами. Они позволяют управлять изменениями, не нарушая существующую функциональность.
Ключевые аспекты:
- Версионирование контрактов: поддержание совместимости старых и новых версий интерфейсов, схем сообщений и DTO.
- Anti-Corruption Layer: защита доменной модели от нежелательных влияний внешних контекстов, трансляция и обогащение данных на границе.
- Эволюция схем: управление изменениями в событиях и DTO/XML/JSON-форматах без разрушения подписчиков и потребителей.
- Контрактное тестирование: автоматические тесты на совместимость контрактов, включая тесты совместимости между версиями.
Интеграционные контракты часто реализуются через событийные механизмы или синхронные вызовы между Bound Contexts. Важно держать контракты в легком для изменения виде и разделить ответственность между доменной моделью и контрактным слоем. Примеры практик включают:
- Публикацию доменных событий для оповещения других контекстов об изменениях состояния.
- Версионирование сообщений и DTO, совместимое с предыдущими версиями.
- Четкие соглашения по форматам и обязательным полям в контрактах.
- Тесты контрактов между сервисами, проверяющие совместимость версии.
Формирование эффективной стратегии интеграции требует осознанного подхода кary, что любые изменения в инфраструктурном слое, репозитории или фабриках отражаются через контрактную часть. Это позволяет минимизировать риск возможных сбоев при развёртывании и одновременном изменении нескольких контекстов.
Управление изменениями и практики внедрения
Эволюция доменной модели требует системного подхода к управлению изменениями. В контексте репозиториев, фабрик и доменных сервисов изменений должно быть больше внимания к совместимости, migrate-пути и безопасной миграции данных.
Практики:
- Поэтапная миграция схем и контрактов: ввод новой версии контракта, поддержка старой версии в течение переходного периода.
- Депрецизация и deprecation-планы: заранее объявлять планы по устаревшим API и контрактам, обеспечивая плавное отключение.
- Тестирование контрактов и интеграций: автоматизированные тесты на совместимость между версиями доменной модели и интеграционной инфраструктурой.
- Управление зависимостями между слоями: изменение интерфейсов репозиториев и фабрик должно проходить через согласование с командой разработки и тестами.
Изменения в доменной модели должны быть минимально инвазивными, и их нужно внедрять через новые фабрики и репозитории, сохраняя существующие до момента полной миграции. В случае крупных изменений следует рассмотреть вариант временной поддержки нескольких параллельных версий контракта, переключения клиентов на новую версию через флаг или конфигурацию, а также внедрение адаптеров, которые выполняют трансформацию между версиями.
Key takeaways
- Репозитории предоставляют persistence-абстракцию на границе Bound Context и должны сохранять бизнес-логику в доменной модели, а не в инфраструктуре.
- Фабрики обеспечивают единый путь создания агрегатов и соблюдение инвариантов на старте их жизненного цикла.
- Доменные сервисы координируют операции между агрегатами и инкапсулируют сложную бизнес-логику, не подходящую для одной сущности.
- Интеграционные контракты и Anti-Corruption Layer уменьшают риск разрыва моделей между контекстами при эволюции моделей.
- Управление изменениями требует стратегий версионирования контрактов, тестирования совместимости и постепенной миграции к новым версиям.
- Хорошая архитектура репозиториев, фабрик и доменных сервисов упрощает тестирование, сопровождение и дальнейшую эволюцию системы.
- В рамках практик рекомендуется держать инфраструктурные детали отдельно от доменной модели, обеспечивать тестируемость и поддерживать ясные контрактные границы.
FAQ
Вопрос 1: Как выбрать, какие операции держать в доменных сервисах, а какие в сущностях?
Ответ: Операции, которые требуют координации между несколькими агрегатами, не зависят напрямую от состояния одного агрегата или нарушают инварианты конкретной сущности, целесообразно поместить в доменный сервис. Если операция тесно связана с состоянием одного агрегата и поддерживает его инварианты, она может быть реализована внутри самой сущности или внутри агрегата. Разделение следует делать с учетом чистоты модели: не перегружать сущности бизнес-логикой, которая выходит за рамки их ответственности, и не превращать доменные сервисы в функциональные аналоги репозитория.
Вопрос 2: Как обеспечить устойчивость к изменениям контрактов между контекстами?
Ответ: Необходимо применить версионирование контрактов, поддерживать обратную совместимость, использовать Anti-Corruption Layer и публиковать доменные события для оповещения об изменениях. Контракты должны быть детерминированы, тестируемы и документированы. Важно согласовать стратегию миграции: новая версия контракта вводится параллельно старой, клиентам дается переходный период, после чего устаревшие версии снимаются.
Вопрос 3: Какие сигнатуры репозиториев оптимальны для тестирования?
Ответ: Интерфейсы репозиториев должны быть сосредоточены на поведении, а не на деталях хранения. Предпочтительно использовать асинхронные методы и единый контракт сохранения изменений через Unit of Work. Тесты должны покрывать сценарии чтения/записи, редкие случаи ошибок и реакцию на невалидные данные. В тестах полезно использовать in-memory реализации репозиториев или мок-объекты, чтобы изолировать бизнес-логику.
Вопрос 4: Какие риски связаны с неправильной эволюцией модели?
Ответ: Риск включения бизнес-правил в техническую логику инфраструктуры, нарушение инвариантов агрегатов, сложности тестирования, нарушение совместимости между контекстами и появление анти-архитектурных связей. Чтобы снизить риски, необходимо планировать изменения через фабрики и сервисы, поддерживать версионирование контрактов и регулярно проводить contract tests.
Вопрос 5: Какие принципы тестирования применимы к репозиторию и фабрикам?
Ответ: Тесты должны проверять коррекцию поведения на уровне контрактов, соответствие инвариантам и корректность создания через фабрику. Тесты репозиториев фокусируются на конвергенции между доменной моделью и хранением (например, восстановление агрегата по идентификатору, сохранение изменений). Важно тестировать сценарии миграций и эволюции контрактов, чтобы гарантировать отсутствие регрессии.
Вопрос 6: Как обеспечить поддержку нескольких версий контракта в инфраструктуре?
Ответ: Введите Explicit versioning в контрактах и маршрутизацию по версии, используйте адаптеры для трансформации данных между версиями, сохраняйте Backward-compatibility. Дайте клиентиверам возможность выбрать версию контракта через конфигурацию или флаг, чтобы минимизировать риски перехода.
Вопрос 7: Что такое Anti-Corruption Layer и как его применить к репозиториям?
Ответ: Anti-Corruption Layer (ACL) - это набор адаптеров и трансляций между контекстами, который защищает доменную модель от нежелательных влияний. В контексте репозитория ACL может реализовать преобразование внешних данных в форму доменной модели, скрывая различия в форматах и поведении между контекстами. Это позволяет контролировать зависимость от внешних изменений и снижает риск мигрировать бизнес-правила в инфраструктуру.
Вопрос 8: Как связать изменения модели с изменениями в пользовательских сценариях?
Ответ: Изменения в доменной модели должны быть согласованы с продуктовой стратегией и сценариями внедрения. Включайте бизнес-метрики и сценарные тесты, чтобы проверить, как новые инварианты влияют на реальные сценарии использования. Применяйте постепенное внедрение через feature-toggles и пилоты, чтобы минимизировать риск.
Вопрос 9: Какие практики помогают обеспечить устойчивость к будущим изменениям?
Ответ: Ведите модульную архитектуру с четкими границами контекстов; используйте контрактные тесты; развивайте инфраструктуру вокруг репозиториев и фабрик (Unit of Work, lazy-loading, caching); применяйте события и реактивные паттерны для асинхронной интеграции между контекстами; регулярно переоценивать границы контекстов в ответ на новые бизнес-потребности.
Вопрос 10: Как внедрять эти паттерны в существующие проекты?
Ответ: Начните с выделения Bound Context и определения границ агрегатов. Введите репозитории как контракт между доменной моделью и инфраструктурой, добавьте фабрику для сложных агрегатов и реализуйте доменные сервисы там, где логика выходит за пределы одного агрегата. Постепенно заменяйте существующие реализации на новые, внедряйте Anti-Corruption Layer для внешних взаимодействий и создавайте контрактные тесты для гарантии совместимости. Важно обеспечить вовлечение бизнес-стороны и продуктовых команд на каждом этапе, чтобы новые паттерны соответствовали ожиданиям и потребностям бизнеса.
