Означает ли Anemic Domain Model, что вы не можете использовать служебные / вспомогательные классы в качестве «помощников» для вашей доменной модели?

Question

Согласно этому определению , концепция Фаулера модели анемичной области:

модель предметной области, где бизнес-логика реализована снаружи доменные объекты

и

С этим шаблоном логика обычно реализованы в отдельных классах, которые преобразовать состояние домена объекты. Фаулер называет такие внешние скрипты транзакций классов.

Если мы возьмем пример корзины покупок, объектом корзины будет объект домена. Но чтобы обработать корзину до окончательного заказа и получения, необходимо проверить инвентарь заказа и обработать платеж кредитной картой. Многие из этих вещей требуют служебных классов, так как выполнение всего лишь внутри объекта Cart будет означать, что класс Cart будет огромным и громоздким. Итак, означает ли это, что Cart в этом примере будет Anemic Domain Model, а эти служебные классы будут "сценариями транзакций" в соответствии с определением выше?

Answer 1

Ключевой концепцией доменного дизайна является создание богатого дизайна, который передает и отражает жаргон своих доменных экспертов (бизнес-пользователей). Затем вы хотите, чтобы ваш код стал выражением этой доменной модели. (см. «Повсеместный язык» и «Дизайн на основе моделей» в сводках DDD Patterns ).

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

Имея это в виду, может быть полезно рассмотреть, как вы относитесь к своим "вспомогательным" или "служебным" классам. Используя некоторые из ваших описаний, у вас могут быть классы и методы, такие как:

product = GetProduct(data.productId);
shoppingCart.add(product);
receipt = customer.Purchase(shoppingCart);

Ваш метод Customer.Purchase может выполнять следующие действия:

creditCard = this.getCreditCart(creditCardNumber);
purchaseNumber = creditCard.Charge(shoppingCart.Total);

Я понимаю, что эти примеры не являются полными или даже полностью точными, но я надеюсь, что идея полезна.

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

Надеюсь, это поможет. Удачи!

Answer 2

Как сказал Крис, нормально иметь вспомогательные классы поддержки, если эти вспомогательные классы сопоставлены с сущностями реального домена, обнаруженными на языке пользователя. Иногда множество «вспомогательных классов» является симптомом анемичной модели, если они связаны с классами, которые в основном имеют сеттеры и геттеры (в этих сценариях помощники вырастают из поведения, которое неправильно назначается объектам домена).