DDD分战术模式(架构设计/模型设计)与战略模式(业务分析)
读后感的范围是战术模式 (涉及 聚合根,实体,值对象, 领域服务, 工厂, 资源库）以及涉及的一些知识
① 知道必须按照领域知识分析建模, 而不是表建模
② 建模后按照 战术模式review模型 并设计好编
初步建模的方法论, DDD上是不完善的, 但是在初步建模之后， 分析/调整模型 到最后编码落地, 这块DDD是很不错的
//一个对象的基本构成
//8个基本类型 + String + 另外一个对象
Customer {
String name;
int age;
Address address;
}
1 值对象
在讲实体之前, 先讲讲值对象:
① 值对象只是一个值，类似（int a = 3）中的『3』，只不过是用对象来表示。值对象虽然是只读的，是一个完整的不可分割的整体，但是可以被整个替换掉：类似（a = 4）把a的值由『3』替换为为『4』，
eg: java基本类型 long int short byte boolean, char, double , float 以及string
那么在这里断言, java的基本类型(包含装箱) + string 是值对象, 值对象是可读不可变的(值变了就是替换)
② 某些实际的对象也是值对象, 例如 customer关联了一个address（不被外界关联）
eg: 当修改 Customer 的 Address 对象引用时，不是通过 Customer.Address.Street 这样的方式来修改属性，可以这样做：Customer.Address = new Address(…)
总结：
- 值对象没有唯一标识，这是它和实体的最大不同。值对象在判断是否是同一个对象时是通过它们的所有属性是否相同，如果相同则认为是同一个值对象。在区分是否是同一个实体时，只看实体的唯一标识是否相同，而不管实体的属性是否相同。
- 值对象是不可变的，即所有属性都是只读的，所以可以被安全的共享。
2 实体
在一个聚合根中, 所有的属性要么是值对象(基本类型加不变对象), 要么是实体
那么实体与值对象有什么不同的了：
- 实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体：有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，也认为他们是两个不同的实体。
- 不应该给实体定义太多的属性或行为，而应该寻找关联，将属性或行为转移到其他关联的实体或值对象上。比如：Customer 实体，有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以我们可以定义一个 Address 对象，然后把 Customer 的地址相关的信息转移到 Address 对象上。如果没有 Address 对象，而把这些地址信息直接放在 Customer 对象上，然后对于一些其他的类似Address的信息也都直接放在Customer 上，会导致 Customer 对象很混乱，结构不清晰，最终导致它难以维护和理解。
3 聚合根
1 充血模型
我们现在用的SSH or SSM 其实是面向过程的, 我们使用的模型都是贫血模型, 只有属性, 没有行为
例如:
保存顾客的例子
public class Customer {
private int id;
private int age;
private string name;
private String address;
///下面一大坨getter setter
// 米有任何业务逻辑
}
public class CustomerService {
private CustomerMapper customerMapper;
public Customer save(Customer customer) {
return customerMapper.save(customer);
}
}
public class CustomerController {
private CustomerService customerService;
//处理方式
@ReuqestMapper(method=POST)
public Customer save(Customer customer) {
return customerService.save(customer);
}
}
controller → service → mapper
真真的模型应该是充血的, 同时具有属性与行为:
//修改名字的例子
public class Customer extends Model{
private int id;
private int age;
private string name;
private String address;
///下面一大坨getter setter
//具有具体的修改的行为
public Customer changeName(String newName) {
customer.name = name;
customer.save();
return customer;
}
}
public class CustomerController {
@ReuqestMapper(method=PUT )
public Customer changeName(String name) {
Customer customer = Customer.findById(id);
//不考虑null
customer.changeName(newName);
return customer;
}
}
controller 直接调用模型
面向过程感觉是 模型都有我们来操纵
面向对象感觉是 模型的行为都是自发的
从维护性上来说， 面向对象显然更好理解, 而且砍掉了SPRING体系下产生一套没啥用的代码, 代码更加聚焦。
2 划分领域
|
有一个疑问就是充血模型会关联外部对象, 那么在一个系统中如此关联下去结果可能如下
模型直接互相关联最终会产生一个巨大的蜘蛛网, 那么这样的代码耦合性太大了! 这个时候DDD出现了, 他要求我们从领域划分对象，落地到代码是这样的
这个时候你们肯定有疑问, 为什么items还是保留在Order里面
我们看下聚合根的定义 聚合有以下特点：
另外在DDD中有一条原则：一个业务用例对应一个事务，一个事务对应一个聚合根，也即在一次事务中，只能对一个聚合根进行操作 那如何划分出聚合根了? 简单的方法: 生命周期是否一致(一起诞生, 一起消亡) 另外聚合根要求
你可以看到orderItems 是符合这几点要求的
4 领域服务每个领域模型负责自己领域的行为, 比如用户改名, 比如查看订单下订单子项个数
3 DDD建模过程
领域建模是一个不断重构，持续完善的过程，大家会在讨论中将变化的部分反映到模型中，从而模型不断细化并朝正确的方向走。 4 关联的设计关联在领域建模的过程中非常重要，关联的设计可以遵循如下的一些原则：
|
扫一扫
166
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
