Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.

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