Руководство по организации исходного кода решения (OO / DDD) - PullRequest
Новая
       30

Руководство по организации исходного кода решения (OO / DDD)

3 голосов
/ 26 мая 2010

Я начинаю свой первый бизнес-проект (.NET) и пытаюсь следовать принципам DDD.Существуют ли какие-либо руководящие принципы или общие шаблоны для организации исходного кода и пространств имен?

Например, объекты вашего домена входят в пространство имен MyProject.Domain или что-то еще?Вы бы разделили конкретные реализации и интерфейсы?В разных пространствах имен?Разные папки?Разные решения?

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

Ответы [ 2 ]

2 голосов
/ 31 мая 2010

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

  • Одно решение в ограниченном контексте
  • Один проект домена, содержащий модель (сущности, объекты значений, интерфейсы репозитория и т. Д.)
  • Один проект Domain.Persistence (или DataAccess), содержащий сопоставления NHibernate, реализации репозитория и типы, специфичные для NHibernate. Если у вас есть серьезные планы иметь более одного уровня персистентности, вы можете назвать их Domain.Persistence ..
  • Один прикладной проект, содержащий код прикладного уровня (сервисы)
  • Любое количество проектов пользовательского интерфейса или службы Windows

Взгляните на мой DDDSample.Net проект. Он содержит много вариантов решения DDD для той же проблемы. Я только что описал самый типичный простой, но есть и более сложные, а именно:

  • Модель с несколькими слоями
  • Система CQRS
  • Система Event Sourcing CQRS

Надеюсь, это поможет.

1 голос
/ 26 мая 2010

Я тоже новичок в этом, но вот что я сделал.

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

  • Company.Core имеет несколько пространств имен:

    .Data определяет интерфейсы для нашего DAL

    .Repository определяет базовые интерфейсы для наших репозиториев

  • Company.Data представляет собой конкретную реализацию DAL

  • Company.Domain - это доменные объекты, в которых определены интерфейсы репозитория

  • Company.Repository - конкретная реализация репозиториев

  • Company.Tests имеет много пространств имен:

    .Data проверяет DAL, .Data.Mock проверяет его

    . Репозиторий тестирует репозитории, .Repository.Mock их издевается

    .Domain тестирует доменные объекты с помощью фиктивных репозиториев

Все это связано с AutoFac

...