Как ВЫ учитываете свой Домен (пространства имен) при проектировании, ориентированном на домен?
-
03-07-2019 - |
Вопрос
Как ВЫ учитываете свой Домен (пространства имен) при проектировании, ориентированном на домен?
Я перехожу к следующей концепции:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
Например, у меня есть объект в CMS под названием "Content".Итак, я бы создал проект под названием Project.Content и распределил классы так, чтобы они выглядели как:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
Эта модель сущности "Content" будет иметь свое собственное пространство имен.
Но я нахожу, что это плохо масштабируется в крупной корпоративной среде с более чем дюжиной проектов (попробуйте 18) моделей "Сущностей".В итоге я получаю решение с более чем дюжиной проектов, некоторые из которых имеют только 2 или 3 класса (т.Е.UrlRewriter).Кроме того, я ловлю себя на том, что ссылаюсь на другие проекты только из-за их интерфейсов.Я чувствую, что это загрязняет мой домен;хотя это и не конкретные ссылки, иногда бывает трудно удержаться от циклических ссылок.
Поэтому я время от времени возвращаюсь к концепции "Слоя"...
Я хочу знать, как другие эксперты DDD учитывают приложения корпоративного размера.Пожалуйста, не стесняйтесь рекомендовать книги и статьи.
И заранее спасибо!
Решение
Первое, что я думаю сделать, - это добавить к нему что-то, что идентифицирует ограниченный контекст.
Ps.чтобы убедиться, что понятно почему, проверьте обе ссылки в ограниченном контексте: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx
Другие советы
Я пользуюсь, следуя рекомендациям .NET . Я нахожу их очень интуитивно понятными, и они позволяют вам настраивать пространства имен так, чтобы вам не нужно было импортировать то, что вам не нужно.
Я бы никогда не навязал строгое соглашение об именах для уровня функций. Дизайн каждого отдельного проекта должен руководить этим.
Я, как и вы, обнаружил, что управлять большим количеством проектов становится непросто.Я предпочитаю
Project.Domain
Project.DataAccess
Project.Presentation (presenters and such)
Project.Gui (in case of a winforms app)
настройка.
В каком-то смысле упрощение вещей очень помогает, когда дела идут плохо.
Вопрос в том , что вы получаете , создавая еще один проект ?(это очень легко сделать, почти легко)
Захотите ли вы когда - нибудь использовать этот проект самостоятельно или нет ?В итоге вы можете получить .библиотеки DLL настолько взаимосвязаны, что вы даже не сможете развернуть их, не имея точно таких же версий и т.д.в этом случае нет особых причин разделять его и загромождать вашу IDE)
Вы всегда можете перенести что-то в новый проект позже, если возникнет необходимость, это несколько болезненно, но к тому времени у вас будет веская причина сделать это, помимо простого ощущения того, как это делается.