Как организовать доменный дизайн-проект? - PullRequest
27 голосов
/ 09 февраля 2009

Я начал изучать DDD и хотел знать, как другие организовали свои проекты.

Я начал с организации вокруг моих AggregateRoots:

MyApp.Domain (пространство имен для модели домена)

MyApp.Domain.Product
- Продукт
- IProductService
- IProductRepository
- и т. д.

MyApp.Domain.Comment
- Комментарий
- ICommentService
- ICommentRepository
- и т. д.

MyApp.Infrastructure
- ...

MyApp.Repositories
- ProductRepository: IProductRepository
- и т. д.

Проблема, с которой я столкнулся, заключается в том, что я должен ссылаться на свой доменный продукт как MyApp.Domain.Product.Product или Product.Product. Я также получаю конфликт с моей моделью данных linq для продукта .... Мне приходится использовать некрасивые строки кода, чтобы различать их, такие как MyApp.Domain.Product.Product и MyApp.Respoitories.Product.

Мне действительно интересно посмотреть, как другие организовали свои решения для DDD ...

Я использую Visual Studio в качестве своей IDE.

Большое спасибо.

Ответы [ 5 ]

20 голосов
/ 09 февраля 2009

Я стараюсь сделать все очень просто, когда могу, поэтому обычно что-то вроде этого работает для меня:

Myapp.Domain - все доменные классы совместно используют это пространство имен

Myapp.Data - Тонкий слой, который абстрагирует базу данных от домена.

Myapp.Application - все «коды поддержки», ведение журнала, общий код утилит, потребители услуг и т. Д.

Myapp.Web - веб-интерфейс

Таким образом, классы будут, например:

  • Myapp.Domain.Sales.Order
  • Myapp.Domain.Sales.Customer
  • Myapp.Domain.Pricelist
  • Myapp.Data.OrderManager
  • Myapp.Data.CustomerManager
  • Myapp.Application.Utils
  • Myapp.Application.CacheTools

1029 * Etc. *

Идея, которую я пытаюсь запомнить, заключается в том, что пространство имен «домен» - это то, что отражает реальную логику приложения. Итак, о чем вы можете поговорить с «экспертами в области» (парнями, которые будут использовать приложение). Если я кодирую что-то из-за того, что они упомянули, это должно быть в пространстве имен домена, и всякий раз, когда я кодирую что-то, чего они не упомянули (например, ведение журнала, отслеживание ошибок и т. Д.), Это НЕ должно быть в пространстве имен домена.

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

С этой целью я обычно не начинаю с размышления о паттернах во всех деталях. Я пытаюсь смоделировать домен настолько просто, насколько могу, просто следуя стандартным руководствам объектно-ориентированного проектирования. Каким должен быть объект? Как они связаны?

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

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

В моем примере Myapp.Domain.Sales.Order будет агрегатным корнем в том смысле, что при его создании он, скорее всего, будет содержать другие объекты, такие как объект клиента и набор строк заказа, и вы будете иметь доступ только к строки заказа для этого конкретного заказа через объект заказа.

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

Так что я буду ссылаться на такие вещи, как:

Myapp.Domain.Sales.Order.TotalCost

Myapp.Domain.Sales.Order.OrderDate

Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod

Myapp.Domain.Sales.Order.Customer.Address.Zip

и т.д.

5 голосов
/ 11 февраля 2009

Мне нравится иметь домен в корневом пространстве имен приложения в его собственной сборке:

Acme.Core.dll [корневое пространство имен: Acme]

Это четко отражает тот факт, что домен входит в сферу действия всех остальных частей приложения. (Подробнее см. Луковая архитектура Джеффри Палермо).

Далее у меня есть сборка данных (обычно с NHibernate ), которая отображает объекты домена в базу данных. Этот уровень реализует интерфейсы хранилища и службы:

Acme.Data.dll [корневое пространство имен: Acme.Data]

Затем у меня есть презентационная сборка, объявляющая элементы моего шаблона выбора:

Acme.Presentation.dll [корневое пространство имен: Acme.Presentation]

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

Acme.Web [корневое пространство имен: Acme.Web]

3 голосов
/ 12 марта 2009

Несмотря на то, что вы также являетесь разработчиком .Net, справка по реализации Java приложения Cargo от DDD от Eric Evans и Citerus является хорошим ресурсом.

В коде документа вы можете увидеть DDD-организацию в ограниченном контексте и агрегатах в действии прямо в пакетах Java.

Кроме того, вы можете рассмотреть Sharp Architecture Билли МакКафферти . Это ASP.Net MVC, реализация NHibernate / Fluent NHibernate, созданная с учетом DDD.

По общему признанию, вам все еще нужно будет применить решение для папок / пространств имен, чтобы обеспечить контексты. Но, соедините подход Эванса с #Arch, и вы должны быть в пути.

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

Счастливое кодирование,

Курт Джонсон

0 голосов
/ 11 февраля 2009

Я бы проверил codecampserver, так как настройки там довольно распространены.

У них есть основной проект, в который входят как прикладной, так и доменный уровни. То есть внутренности лука (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/).

Мне действительно нравится разбивать ядро ​​на отдельные проекты, чтобы контролировать направление зависимости. Так что обычно у меня есть:

MyNamespace.SomethingWeb <- несколько пользовательских интерфейсов <br> MyNamespace.ExtranetWeb <- несколько пользовательских интерфейсов </p>

MyNamespace.Application <- прикладной уровень Эванса с такими классами, как CustomerService <br> MyNamespace.Domain

  • MyNamespace.Domain.Model <- entity </li>
  • MyNamespace.Domain.Services <- услуги doman </li>
  • MyNamespace.Domain.Repositories

MyNamespace.Infrastructure <- реализация репо и т. Д. </p>

MyNamespace.Common <- Проект, от которого зависят все другие проекты, и который имеет такие вещи, как Logger, классы Util и т. Д. </p>

0 голосов
/ 11 февраля 2009

Ваш домен, вероятно, имеет имя, так что вы должны использовать это имя как пространство имен.

Я обычно ставлю репозиторий реализация и доступ к данным детали в пространстве имен под названием Стойкость под доменом Пространство имен.

Приложение использует свое имя в качестве пространства имен.

...