DDD с ORM, где должна идти бизнес-логика?

10

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

Большая часть бизнес-кода и сервисов, работающих в домене, были частью модели, и наши репозитории возвращали бизнес-объекты (поэтому было бы невозможно переключиться на другой ORM (не то, что мы хотели)).

Тем не менее, сейчас я начинаю проект, и я хочу думать с точки зрения DDD.

До сих пор кажется, что я поместил свою бизнес-логику в свою модель предметной области и через репозитории я бы работал с ORM (который я когда-либо выбирал). Однако, если бы я хотел продолжать использовать инструмент MDA для части приложения ORM, созданная здесь модель была бы очень анемичной (то есть не содержала бы никакой бизнес-логики). Точно так же, если бы я использовал Entity Framework (.net) или NHibernate для моего ORM, это тоже было бы анемичной моделью. Я не уверен, куда бы вы положили бизнес-логику, если бы я просто использовал NHibernate.

Правильно ли я так думать, другими словами, с DDD вся бизнес-логика в домене и просто использовать ORM для сохранения через репозитории?

JD01
источник

Ответы:

12

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

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

До сих пор кажется, что я поместил свою бизнес-логику в свою модель предметной области и через репозитории я бы работал с ORM (который я когда-либо выбирал). Однако, если бы я хотел продолжать использовать инструмент MDA для части приложения ORM, созданная здесь модель была бы очень анемичной (то есть не содержала бы никакой бизнес-логики). Точно так же, если бы я использовал Entity Framework (.net) или NHibernate для моего ORM, это тоже было бы анемичной моделью. Я не уверен, куда бы вы положили бизнес-логику, если бы я просто использовал NHibernate.

Анемичная модель предметной области считается плохой практикой для многих, например, для Мартина Фаулера. Вы должны избегать такого дизайна, потому что такая модель ведет к методическим методам проектирования, а не к хорошему объектно-ориентированному дизайну. Затем у вас есть классы данных и классы менеджера / обработки, что означает, что вы разделяете состояние и поведение. Но объект действительно должен быть «состоянием и поведением».

NHibernate отлично справляется с невежеством. Вы можете скрыть детали отображения в XML или с помощью FluentNHibernate и просто написать простые POCO. С помощью NHibernate очень легко создать богатую модель предметной области. Я думаю, что вы можете сделать это с помощью структуры сущностей и инструмента MDA. Пока этот инструмент создает частичные классы, вы можете легко расширять сгенерированный код, не беспокоясь о том, что новое поколение может уничтожить ваш пользовательский код.

Короче говоря, эта длинная история. Когда вы используете NHibernate, ничто, я повторяю, ничего не мешает вам использовать модель богатого домена. Я рекомендую использовать его с FluentNHibernate и составлять карты вручную. Код сопоставления занимает всего 5-10 минут. Я полагаю, что то же самое верно для структуры сущностей и что ее инструменты по крайней мере создают частичные классы, которые легко расширяемы.

Правильно ли я так думать, другими словами, с DDD вся бизнес-логика в домене и просто использовать ORM для сохранения через репозитории?

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

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

сокол
источник
2
+1: я также отделяю уровень логики домена от уровня логики приложения. Я поместил весь ORM и материал базы данных в слой логики домена. Уровень прикладной логики ничего не знает об ORM, транзакциях и тому подобном: он видит только классы бизнес-логики и вызывает их методы. Я считаю, что этот подход очень эффективен для создания более простого и чистого логического уровня приложения.
Джорджио
@Falcon: Спасибо за информацию. Когда я упомянул анемическую модель, я имел в виду, что если я создаю домен с использованием DDD, одной из версий моих репозиториев может быть версия mda, где я просто перемещаю свои сущности в сущности mda (то есть анемичную модель), а затем сохраняю их в транзакциях и т. д. Это было бы хорошо? Я сомневаюсь, что буду использовать инструмент MDA, но просто пытаюсь понять, как могу, если захочу. Это звучит правильно?
JD01
@ JD01: Я вас не совсем понимаю, но звучит так, будто вы хотите преобразовать сущности модели предметной области, чтобы вы могли легко их сохранить. Это в значительной степени похоже на использование DTO, и automapper (google it) может быть полезным инструментом для такой задачи. Такой подход не обязательно противоречит лучшим методам DDD. В конце концов, хранилища также предназначены для сокрытия логики доступа к данным. Вы можете просто трансформировать свои бизнес-объекты за кулисами в MDA DTO, а затем сохранить их, а пользователь API даже не заметит. Я думаю, что все в порядке.
Сокол
1
@ JD01: Я предлагаю вам взглянуть на следующую ссылку, чтобы увидеть, как много ребят из Enterprise Java делают это. Они в основном имеют DAO, DTO и BO (бизнес-объект). Для меня это слишком много слоев, но дизайн в порядке. java.sun.com/blueprints/corej2eepatterns/Patterns/…
Сокол
@Falcon: Да, я думал, что DTO - это мои объекты MDA, а не то, что я пойду этим путем. Просто получить контроль над тем, что каждая часть игроков DDD d0. Еще раз спасибо.
JD01
3

Однако, если бы я хотел продолжать использовать инструмент MDA для части приложения ORM, созданная здесь модель была бы очень анемичной (то есть не содержала бы никакой бизнес-логики).

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

Тем не менее, я чувствую, что инструменты MDA немного менее подходят в контексте DDD, чем ORM, потому что генерация кода часто имеет тенденцию создавать классы, которые запутаны с шумом, характерным для инструмента, вместо обтекаемых, четко выраженных объектов домена, которые мы ожидаем. На самом деле то, что вы часто получаете, - это сочетание данных домена, логики постоянства, логики проверки ограничений ... и я не знаю, есть ли способ разделить эти проблемы с большинством инструментов MDA.

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

Кроме того, я думаю, что Falcon в значительной степени сказал все это - абсолютно ничего в инструментах ORM или MDA не мешает вам иметь богатые доменные сущности.

guillaume31
источник
Привет, я использую ECO (корпоративные объекты ядра) с ableobjects.com, и это именно то, что вы описали.
JD01
1

Что я делаю в своей команде, так это моделирую свой объект, домен и одновременно добавляю свою бизнес-логику. Я не использую Model Driven Development, которая генерирует код из модели, но предпочитаю подход аннотации. Я имею в виду, что на уровне объекта внутри диаграммы классов я добавляю стереотипы ORM. Это добавит аннотации постоянства непосредственно в код, которые совместимы с EJB3 / hibernate. Создание базы данных выполняется Hibernate, а не шаблонами UML. Это намного лучше, потому что, если код изменяется и добавленные аннотации не совсем то, что специалист по спящему режиму, он может изменить его, но модель все еще хороша. Я также могу изменить свои требования, и моя модель домена все еще в порядке.

Разработчики могут добавлять бизнес-логику в каждый метод и добавлять комментарии, я также могу моделировать и добавлять ограничения. Например, объем продаж должен превышать 50 тыс., Если нет, и т. Д. Мне не нужно кодировать его, а просто написать в модели, и эта информация будет видна команде разработчиков. Действительно крутой и гибкий UML.

UML_GURU
источник