Чи "Інверсія контролю" сприяє "анемічній моделі домену"?

Коли я використовував IoC Container в своєму останньому проекті, я стикався з анемічними сутностями та більшою частиною своєї бізнес-логіки в службах без громадянства.

Я бачив проекти, написані іншими розробниками, які використовують "Інверсію контролю", і вони завжди "анемічні".

Оскільки "Анемічна модель домену" є антидіаграмою, чи можна використовувати IoC та Rich Domain? Чи є їхні хороші приклади, проекти з відкритим кодом, які роблять це?

Для початку: DI та IoC не є синонімами. Мені шкода, але я мушу це зазначити (мені здається, ти думаєш, що вони є).

Що стосується вашого запиту ... Ну, введення залежностей - це лише інструмент. Як ви збираєтеся використовувати цей інструмент - це зовсім окрема річ. Існують також інші інструменти (схеми дизайну), які можуть доповнити проблему. Наприклад, я вважаю, що широке прийняття шаблону MVC є одним з ключових компонентів для формування антидіапазону моделі Anemic Domain Model: контролери (у більш простих програмах, у складніших, які були б додатковими службовими рівнями) беруть на себе відповідальність за перевірку правил бізнесу , примусово застосовуючи їх, а також перетворюючи об'єкти БД у щось корисне, тоді як бізнес-шар перетворюється на простий рівень доступу до даних, який є простим ORM з відображенням один на один, до об'єктів бази даних.

Звичайно, саме так ви розробляєте свою програму - ви можете створити правильну модель домену, якщо хочете, і всі ці IoC, DI, MVC вас не зупиняють. Що може зупинити вас - ваша команда. Вам потрібно якось переконати їх у використанні правильного шляху, і це може бути важко, оскільки багато розробників програмного забезпечення не мають сильного архітектурного походження.

Більшість програм (якщо не всі) є сукупністю проблем інфраструктури та домену. Коли ви досягнете певного рівня складності, вам буде легше керувати, якщо домен відокремлений від інфраструктури, щоб було простіше міркувати і еволюціонувати самостійно.

Звичайно, доменна модель все ще потребує зв'язку з рештою системи, і зазвичай це буде з службами без громадянства (які є частиною домену), які в них вводять інфраструктурні проблеми (наприклад, доступ до бази даних). Використання контейнера IoC не усуває цю залежність, вона переміщує її конфігурацію в окрему область - знову полегшуючи міркування та підтримку.

Суб'єкти зберігають державу і повинні відповідати за правила ведення бізнесу. Якщо ваші служби застосовують всі інваріанти та інші бізнес-правила, то, швидше за все, логіка не в тому місці.

Тепер, якщо ви знайшли логіку в потрібних місцях і все ж таки закінчилися послугами, які є не більш ніж обгортками навколо інфраструктурних речей та об'єктів, які є лише сумками власності, то дуже ймовірно, що домен недостатньо складний, щоб виправдати. накладні витрати власної моделі. Практично все, що ви прочитаєте про DDD, буде містити відмову, що вона дійсно призначена лише для складних доменів, але це, здається, занадто часто забувається.

Перейдіть до джерела. Почніть з твору Фаулера на моделях Anemic Domain . Він наводить дизайн Еріка Евана, керований доменом як приклад належної практики. Вихідний код для цього знаходиться тут . Завантажте його.

Зауважте, що він використовує Інверсію управління (пошук @Autowired), має класи обслуговування (BookingService) та класи "бізнес-процесів" (наприклад, ItineraryUpdater).

Оригінальна стаття Фоулера починає слід до прикладу, який ви шукаєте.

чи можна використовувати IoC та Rich Domain? Чи є їхні хороші приклади, проекти з відкритим кодом, які роблять це?

Я припускаю, що ви маєте на увазі DI замість IoC, а проект, над яким ви працювали, використовує контейнер DI на зразок Spring. IoC має два основних аромати: DI і Locator. Я не бачу, чому модель «Локатор» повинна бути проблемою, тож давайте зосередимось на DI.

Я не думаю, що це можливо, або, принаймні, це буде дуже недоцільно. Основним аспектом контейнерів DI є те, що вони контролюють створення об'єктів, коли вони вводять їх в інші ("керовані об'єкти"). Набір керованих об'єктів, що живе під час запуску проектів, не залежить від того, які елементи домену існують у вашому проекті, але залежить від того, яким чином об'єкти є проводними та які області (одиночний, прототип) їм призначені.

Ось чому ви не хочете дозволяти контейнеру DI керувати об'єктами вашого домену. Але якщо ви створюєте об’єкти вручну (з новими), ви не можете ін'єктувати інші об’єкти у ваші доменні об’єкти. (Залишаючи потенційні робочі місця з ручним електропроводкою убік.) Оскільки ці ін'єкції потрібні для заміни реалізацій на інші, ви не можете замінити функціональність об'єктів, що мають багатий домен, використовуючи DI. Отже, ви не хочете розміщувати функціональність в об’єктах домену, інакше ви втратите функції DI.

Я не бачу, як може працювати гіпотетичний контейнер DI, який не керує вашими об'єктами, і жодна з існуючих реалізацій цього не дозволяє. Тому справедливо стверджувати, що DI покладається на управління об'єктами. Тому завжди буде спокушати вас розділити потенційні об’єкти Rich Domain на один анемічний клас та один або кілька класів скриптів транзакцій.