Как вы учитываете свой домен (пространства имен) в дизайне, управляемом доменом? - PullRequest
4 голосов
/ 06 марта 2009

Как вы учитываете свой домен (пространства имен) в дизайне, управляемом доменом?

Я перешел к следующей концепции:

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 анализируют приложения корпоративного размера. Пожалуйста, не стесняйтесь рекомендовать книги и статьи.

И заранее спасибо!

Ответы [ 3 ]

1 голос
/ 06 марта 2009

Мне кажется, что я добавляю что-то, что идентифицирует ограниченный контекст.

Ps. чтобы было понятно почему, проверьте обе ссылки в ограниченном контексте: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx

1 голос
/ 06 марта 2009

Я так же, как и вы, обнаружил, что иметь загруженность проектов становится болью в управлении. Я предпочитаю

Project.Domain
Project.DataAccess
Project.Presentation (presenters and such) 
Project.Gui (in case of a winforms app)

установка.

То, как все упрощается, очень помогает, когда дела идут плохо.

Вопрос в том, что вы получаете, когда создаете другой проект? (это очень легко сделать, почти легко)

Вы когда-нибудь захотите использовать этот проект независимо или нет? В результате вы можете получить получившиеся DLL-файлы настолько связанными, что вы даже не сможете развернуть их, не будучи в точности одинаковыми версиями и т. Д. В этом случае нет особых причин разбивать их и загромождать вашу IDE)

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

1 голос
/ 06 марта 2009

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

Я бы никогда не навязал строгое соглашение об именах для уровня функций. Дизайн каждого отдельного проекта должен руководить этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...