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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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