Развивающийся бизнес - DDD или нет?

Question

У меня есть проект, в котором я уже работаю над традиционной трехслойной архитектурой (Entity / Business / UI), и я применяю шаблон репозитория и IoC.

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

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

[Редактировать] Если предположить, что это лучше всего сделать, то:

• Объединение слоя сущностейв бизнес-уровень, а не в отдельности

  (чтобы избежать циклических ссылок, поскольку сущности могут иметь поведение и даже вызывать бизнес-службы в моем понимании)

• Перемещение некоторых бизнес-сервисов в доменные объекты, где это применимо, будет первым шагом к созданию доменной модели?

[Подробнее]

http://en.wikipedia.org/wiki/Domain-driven_design

Необходимые условия для успешного применения DDD:

• Ваш домен не тривиален
• Команда проектаимеет опыт и интерЕсть в OOP / OOD
• У вас есть доступ к экспертам домена
• У вас есть итеративный процесс

Answer 1

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

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

Вы говорите, что бизнес-уровень содержит логику, а не сущности, хотя на самом деле сущности являются бизнес-уровнем (или доменом).

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

Answer 2

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

Так что ответ будет да

Answer 3

Это вряд ли вопрос да / нет.

Работает ли метод бизнес-уровня только с одним экземпляром некоторого класса?Переместите это в класс.

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

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