Должен ли я поместить логику расчета в сущность или в бизнес-уровень?

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

Поэтому мой вопрос заключается в том, имеет ли смысл инкапсулировать простые вычисления в свойствах в классе сущностей?

design-patterns

— Kata
источник

Ответы:

Это зависит от типа архитектуры, которую вы хотите.

В доменно-управляемом дизайне вы создадите модель домена, которая будет иметь как данные, так и функциональность.

Это будет означать, что an Orderимеет свойство (или метод), который будет возвращать общую стоимость заказа на основе OrderLines. У Orderобъекта также будет метод, AddOrderItem(Product product, int amount)и он Orderбудет проверять, есть ли уже OrderLineэтот конкретный продукт.

В такой модели вы бы также имели объекты, которые не являются реальными объектами, например Repository для доступа к данным или Factoryдля создания объектов. Они называются доменными службами. Уровень приложений отвечает за вызов доменных служб (например, для извлечения объекта из базы данных), а затем он выполняет функции на объекте. Оно Application Layerдолжно быть максимально тонким.

Это хорошая статья о DDD которая объясняет эти концепции более подробно.

Вы также можете использовать модель анемичного домена . Это означает, что ваши сущности состоят из свойств get / set и не содержат поведения. В таком дизайне ваш бизнес-уровень будет содержать поведение, такое как вычислениеOrder цены и проверка на дубликат OrderLines.

Существуют разные мнения, является ли модель анемичной области плохой вещью. Лично я предпочитаю настоящую модель предметной области.

В этой статье описываются различия между анемичной и неанемичной моделью предметной области.

— Воутер де Корт
источник

Привет Wouter, спасибо за ответ и ссылку. Мне кажется, что я ошибочно полагаю, что при использовании модели предметной области Anemic вся бизнес-логика (даже очень простая) должна быть помещена в бизнес-уровень. Это кажется бессмысленным в некоторых случаях, когда бизнес-логика действительно зависит от самой модели. Например, свойство рассчитывается на основе существующих свойств в модели. Я не смог найти разумную причину для включения бизнес-логики, которая зависит от самой модели, в бизнес-уровень.

В анемичной доменной модели, как у нас есть бизнес-классы, так и классы сущностей, как правильно именовать классы, чтобы избежать путаницы между ними? Вы предлагаете использовать суффиксы? Если да, не могли бы вы привести пример?

— Kwadz

Для DDD, что если логика расчета цены сложна? Например, цена основана на местоположении (налог), информации о пользователе (скидка при рождении, членская скидка), купоне, кредитной карте (специальная скидка по кредитной карте) и т. Д. Как мы можем поместить такую логику в Orderкласс?

— Sher10ck

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

— Burzum

Анемия ... бедная область звучит так, как будто она страдает от какой-то болезни. Вы бы предпочли быть за рулем ?! Да!

— Мэтт Дженкинс

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

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

Следует помнить одну ключевую вещь: сущность всегда будет иметь личность, но бизнес-объект - это сущность без идентификации. Например, продукт - это сущность, но деньги не будут иметь идентичности. 1000 разных экземпляров денег будут одинаковыми.

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