领域驱动/DDD模型初识
原文:http://www.jdon.com/45378 我们把A对象自身固有行为看成是A的一种能力,而把需要依赖其他对象的方法称为交互行为。哪些属于A的自身方法?哪些属于交互方法?设计思路和方法是如何考虑的? … 那么什么是对象的固有行为?我们认为是那些保证该对象逻辑一致性的行为,称为对象的基本职责,保证自己的存在。 迪米特法则(Law of Demeter)则详细地定义了对象的方法行为,其定义是: 一个对象的方法只应该调用下面对象的方法: 迪米特法则实际从一个公理原则角度对对象的行为设计进行了界定,举例如下: public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
钱包: public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
收款员进行收款时代码如下: //这段代码是位于Payboy类中:
payment = 2.00; // “I want my two dollars!”
Wallet theWallet = myCustomer.getWallet();
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// come back later and get my money
}
这段代码的意思是,检查顾客的钱包中余额,是否足够,然后支付。 注意,检查顾客钱包中余额这一功能是在PayBoy中实现的,PayBoy有权检查顾客的钱足够吗?应该是顾客知道自己钱包余额是否足够。 如果类似Payboy这样调用者进行下面代码: 这不是将顾客这个对象的钱包清空了吗? 这实际就是破坏了顾客这个对象内部的逻辑一致性,顾客对自己的钱包拥有支配权,不能随便将钱包的操作暴露给外界。 也就是说问题出在Customer,它只有setter/getter方法,是一种纯粹的数据结构,是一种失血模型。 我们需要重构Customer,将保证顾客逻辑一致性的行为显式的表达出来,顾客应该拥有这样的基本职责:对自己钱包余额情况有足够了解。 代码实现如下: public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
我们看到,将钱包检查验证是否足够放在Customer这个对象中,这实际也回答了“关于领域驱动设计中的“合法”性校验?”: 这样Payboy的调用代码如下: payment = 2.00; // “I want my two dollars!”
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// say thank you and give customer a receipt
} else {
// come back later and get my money
}
迪米特法则可能带来Customer行为增加,导致复杂性,其实熟悉DDD应该知道,我们可以使用规格模式Specification将那些确保 实体逻辑一致性的合法性检查划分出去,这样,Customer和那些规格对象就组成一个聚合群,成为一个聚合体。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |