Должны ли мы использовать структуру «пакет за особенностью» с DDD?

Question

Проведя некоторые исследования, я получил подтверждение того, что структура папка за элементом превосходит структуру папка за слоем в большинстве случаев.Чтобы получить некоторые аргументы, мы можем прочитать, среди прочего, следующие статьи или даже этот ответ .

Пакет по функциям, а не по слоям
Папки с компонентами и технические папки
Пакет по функциям, а не по слоям
Пакет по слоям для проектов Spring устарел

Однако все примеры проектов DDD, которые я обнаружил, сделаны с package-by-layer , большую часть времени следующиеструктура как:

├── приложение
├── конфиг
├── домен
├── инфраструктура
└── интерфейсы

Так что мойВопрос в том, почему сообщество DDD не следует пакетная функция , даже если в большинстве случаев оно явно превосходит?

Следует ли нам использовать пакетная функция с DDD?Если да, то как это сделать?

Я упоминаю, что Я не говорю о частном случае архитектуры микросервиса , где, очевидно, package-подслой более актуален.

Answer 1

Мое понимание и мое видение этого предмета таковы:

Пакет по признакам - это вертикальная нарезка (структурирование исходного кода в соответствии с концепциями предметной области) вместо горизонтальной наслоения (структурирование в соответствии с техническими концепциями).

Но говорить «вместо» не совсем верно, поскольку есть момент, когда вы должны различать эти технические концепции.Было бы лучше сначала сказать «пакет за элементом», а затем пакет за слоем внутри каждого объекта.

В стратегическом DDD каждый ограниченный контекст (BC) представляет собой вертикальный фрагмент (целое приложение, полный стек ...с помощью пользовательского интерфейса, приложений, модели предметной области и слоев инфраструктуры).

Затем, в рамках BC, тактический DDD способствует сначала упаковке кода модели предметной области в бизнес-концепции, а затем в технические концепции (тактические шаблоны).Итак, у вас есть модули (группы агрегатов, которые тесно связаны и слабо связаны), и внутри каждого агрегата у вас есть сущности, объекты стоимости, фабрики, хранилище.Другие уровни (пользовательский интерфейс, приложение, инфра) также могут быть структурированы по модулям.

Таким образом, в качестве резюме DDD использует смешанный подход:

• Упаковка по бизнесуконцепции с различными уровнями детализации: BC, модули, агрегаты.

• Пакет за слоем внутри BC: пользовательский интерфейс, приложение, домен, инфраструктура.

PD: этот предмет (структура исходного кода) объясняется в главе 9 (Модули) книги Вона Вернона "Внедрение DDD".

Answer 2

почему сообщество DDD не использует пакетные функции

Я думаю, вы обнаружите, что хорошие проекты следуют по пакетам.

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

Менее щедро? авторы не обращают внимания или не знают лучше.

Должны ли мы использовать пакетные функции с DDD? Если да, то как это сделать?

Да, и почти так же, как если бы вы не не выполняли DDD, вы делали бы пакет за функцией. Это ортогональные проблемы.