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 і, звичайно, не шаблонами UML. Це набагато краще, тому що якщо зміна коду та додані анотації не є саме тим, що перебуває у сплячому режимі, то він / вона може його змінити, але модель все-таки хороша. Я також можу змінити свої вимоги, і моя модель домену все ще гаразд.

Розробники можуть додавати ділову логіку всередині кожного методу і додавати коментар, я також можу моделювати та додавати обмеження. Наприклад, продажі повинні становити понад 50 тис., Якщо ні і т. Д. .... Мені це не потрібно кодувати, а просто написати в моделі, і ця інформація могла бути помітна команді розробників. Дійсно крутий і гнучкий UML.