领域模型建模

[FS1360472174]

DDD的全称为Domain-driven Design， 看了书，有点太晦涩，与实际的结合不起来，但是实际的业务代码写的又烂的一比

聚合、实体、值对象、工厂、仓储、领域服务、领域事件

[FS1360472174]

实际的问题

1. mvc模式下，我们通常是对对象进行抽象，而没有对行为进行抽象，关联

2. 特殊的业务规则对应不到代码中 Specification模式

3. MVC模式下，controller,service,dao很容易写出的是过程性代码，而不是面向对象的代码 因为对象只是数据载体，没有行为

[FS1360472174]

1. 通用语言 作用于某个“限界上下文”，在一个特定的限界上下文中只使用一套通用语言，并且保证它的清晰性（避免一个概念在同一个界限上下文中的二义性）和简洁性

比如买家和卖家，都是用户，如果用类型去区分，就会破坏简洁性 ，设计成两个对象,buyer,和consumer会比较好

[FS1360472174]

汤雪华的架构设计

[FS1360472174]

可能存在的理解误区

外部上下文可以作为值对象在本领域建模 而并非是完全隔离的

不管是值对象还是实体和聚合，习惯在构造函数中的做好守卫验证，有利于表达出什么样的领域对象是合法的。

哪些应该在领域对象中做，哪些应该在领域服务中做

[FS1360472174]

1. 领域服务是可以调用反腐层的 还是说在反腐层调用领域服务

必须要区分领域之间的关系， 比如服务拆分出去了，它和另外的领域服务是 Partnership，即生命周期相同，那么他们之间是可以在领域服务中调用的，