Решающий пример модели аномального домена

Question

Я просматриваю области, где я могу оптимизировать дизайн своего инструмента расчета ипотеки, в основном для учебных целей. После прочтения анонимных доменных моделей я заинтересовался созданием Rich Models и заметил, что моя текущая реализация может иметь анемию! Вот текущая реализация в псевдокоде:

class MortgageCalculator { 
    Mortgage mortgage; // mortgage object containing loanAmount, interest rate, etc.; 
    calculateMonthlyPayment(); // calculates monthly payments using mortgage object's properties 
} 

class Mortgage { // Anemic? 
    loanAmount; 
    interestRate; 
} 

В настоящее время объект ипотечного служит в первую очередь для передачи данных между объектами и т.д.

Вот некоторые варианты пересмотра Я рассматривающие:

1. Удалить Ипотечный объект из MortgageCalculator и использует Mortgage чисто как DTO, в то время как методы калькулятора принимают аргументы (например, calculateMonthlyPayment (loanAmount, interestRate). Это поможет с развязкой Ипотека Калькулятор с объекта Ипотека, но все равно будет Ипотека как анемичная модель.
2. Объедините оба класса в одну «богатую» модель MortgageCalculator, которая содержит как бизнес-логику (например, расчетMonthlyPayment), так и свойства ипотеки (например, loanAmount). Мой вопрос заключается в том, что я не уверен, необходимо ли для объекта калькулятора хранить его операнды в качестве переменных экземпляра, но они облегчат передачу, хранение и, возможно, устранение анемии?

Мне интересно, какой будет идеальный подход, или если мне не хватает точки?

Answer 1

Возможно, объект Mortgage может выполнять части вычисления. Например, рассмотрим объект, который вычисляет сумму заказа:

for (Line line : orderLines) 
    int total += line.getPrice() * line.getQuantity(); 

Это является известный как Feature Envy, и может быть:

for (Line line : orderLines) 
    int total += line.calculateTotal(); 

Answer 2

MortgageCalculator не на самом деле домен объект, поскольку он не заполняется в базу данных , поэтому, чтобы избежать анемией можно объединить логику в Mortgage сущности:

class Mortgage { 
    loanAmount; 
    interestRate; 

    calculateMonthlyPayment(); 
} 

Другое дело: DTO отличается от объекта домена, DTO предназначен для передачи данных в среду распространения, тогда как объект домена должен сосредоточиться на логике домена.

Вы можете использовать объект домена как DTO, поскольку в некоторых случаях DTO имеет те же свойства с Domain Entity. Но, в большинстве случаев, зависит от каждого клиента, может быть, им нужно получить данные, требующие нескольких доменов. Таким образом, для разделения беспокойства и более ремонтопригодны, было бы предложено создать DTO разделяться домена объекта:

class MortgageDto { 
    loanAmount; 
    interestRate; 
} 

Answer 3

Вы не можете сделать DDD, если вы не знаете, ваши ограниченные контексты (BC). Итак, что такое БК в этом случае? Потому что все зависит от этого.

Форма, которую я понимаю в вашем случае, я думаю, что хорошо, что у вас есть MortageCalculator, потому что вы можете иметь несколько способов расчета ипотеки. Этот класс может иметь такой метод, который будет принимать аргумент Mortgage. Конечно, то, что я сказал, может быть неправильным, потому что я не знаю вашего домена.

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