Концепции DDD, которые я начал практиковать относительно недавно, напомнили о принципе корня агрегации, который на БД-сущности очень хорошо ложится.
Однако про корни агрегации не стоит забывать и в тех модулях, которые с базой данных никак не связаны. Этот казалось бы очевидный момент несложно упустить, «слепо» следуя SOLID-принципам.
Когда я только знакомился с принципами SOLID — это выглядело как огромный спасательный круг в море legacy-кода, который меня на тот момент окружал :) Действительно, эти архитектурные принципы призывают отказаться от всемогущих god-object и тщательно разделять ответственности между многими классами, которые затем совместно использовать.
Однако в пылу «разделения ответственности» важно помнить о двух важных вещах:
- Если ваш код превращается в набор DTO (объектов без поведения) и сервисов — подумайте еще раз! Хоть это и кажется «идеальным разделением» — поведение отдельно, данные отдельно, но удобства использования от этого значительно поубавится — рядом с объектов вам надо будет таскать и кучку сервисов.
- При изоляции модулей очень хорошим признаком будет наличие лишь одного-двух публично-доступных классов. Таких «корней агрегации» для модуля. Таким образом повторное использование таких библиотек будет простым и понятным.