Как организовать проект, управляемый доменом?

Ответ 1

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

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

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

и др.

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Курт Джонсон

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Уровень приложения MyNamespace.Application < - Evans с такими классами, как CustomerService
MyNamespace.Domain

• MyNamespace.Domain.Model < - entity
• MyNamespace.Domain.Services < - doman services
• MyNamespace.Domain.Repositories

Реализация MyNamespace.Infrastructure &lto - repo и т.д.

MyNamespace.Common < - проект, в котором все другие проекты имеют зависимость от того, что имеет такие вещи, как классы Logger, Util и т.д.