DDD управляемая структура решения - PullRequest
Новая
       81

DDD управляемая структура решения

0 голосов
/ 11 сентября 2018

Я создаю проект, основанный на принципах DDD. Читая ресурсы в интернете, я придумал следующее, имеет ли это смысл? В частности, такие детали, как:

  • Наличие Shared.Core проекта, который совместно используется в ограниченных контекстах
  • Наличие отдельных .Data проектов для каждого ограниченного контекста
  • Наличие Rest.API, которое зависит от Shared.Core и FeatureX.Core проектов.

В следующей таблице показаны созданные мной проекты и их зависимости, -> обозначает «зависит от». 

Rest.API -> Feature1.Core -> Feature1.Data
                          -> Shared.Core
         -> Feature2.Core -> Feature2.Data
                          -> Shared.Core
         -> Shared.Core

1 Ответ

0 голосов
/ 11 сентября 2018

Вы можете называть папки по своему усмотрению, но рекомендуется:

  • у вас есть каталог module / namespace / package /, который не зависит от какой-либо инфраструктуры или технологии (например,REST, SQL, NOSQL, MONGO и т. Д.), Где должна оставаться только ваша бизнес-логика;здесь живут агрегаты, объекты значений, доменные сервисы, саги и т. д. как минимум по одному для каждого ограниченного контекста;давайте назовем это доменным слоем.Это может не зависеть от других уровней домена.Это должно быть без побочных эффектов, легко тестируемым.

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

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

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

Итак, к карте вам уже нужно: 

Rest.API -> Feature1.Domain -> Shared.Lib
         -> Feature1.Infrastructure
         -> Feature1.ACL -> Feature1.Infrastructure
         -> Feature2.Domain -> Shared.Lib
         -> Feature2.Infrastructure
         -> Shared.Lib

Со следующими комментариями:

  • Shared.Lib должен содержать только независимые от технологии библиотеки, не имеющие побочных эффектов, языковые конструкции, функции утилит и т. Д.
  • Feature1.Domain не должен содержать логику из более чем одного домена / ограниченного контекста
  • Feature1.ACL (антикоррупционный уровень) может зависеть от инфраструктуры (т.е. хранить / извлекать из базы данных или кэша), но не должен содержать бизнес-логику, только логику отображения, от удаленных объектов / концепций до локальных объектов / концепций.
...