Как вы учитываете свой домен (пространства имен) в дизайне, управляемом доменом?
Я перешел к следующей концепции:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
Например, у меня есть объект в CMS, который называется «Контент». Итак, я бы создал проект с именем Project.Content и разделил бы классы на следующие:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
Эта модель сущности "Содержимое" будет иметь свое собственное пространство имен.
Но я считаю, что он плохо масштабируется в большой корпоративной среде с более чем дюжиной проектов (попробуйте 18) моделей "Entity". Я получил решение с более чем дюжиной проектов, в некоторых из которых есть только 2 или 3 класса (т.е. UrlRewriter). Кроме того, я ссылаюсь на другие проекты только для их интерфейсов. Я чувствую, что это загрязняет мою область; хотя это не конкретные ссылки, иногда трудно избежать циклических ссылок.
Итак, я иногда прибегаю к концепции «Слоя» ...
Я хочу знать, как другие эксперты DDD анализируют приложения корпоративного размера. Пожалуйста, не стесняйтесь рекомендовать книги и статьи.
И заранее спасибо!