如何实现DCI架构（中）

然而，充血模型并非完美，它也有很多问题，比较典型的是这两个：

问题一：上帝类

People这个实体包含了太多的职责，导致它变成了一个名副其实的上帝类。试想，这里还是裁剪了很多“人”所包含的属性和行为，如果要建模一个完整的模型，其属性和方法之多，无法想象。 上帝类违反了单一职责原则，会导致代码的可维护性变得极差 。

问题二：模块间耦合

School与Company本应该是相互独立的，School不必关注上班与否，Company也不必关注考试与否。但是现在因为它们都依赖了People这个实体，School可以调用与Company相关的Work()和OffWork()方法，反之亦然。这导致 模块间产生了不必要的耦合，违反了接口隔离原则 。

这些问题都是工程派不能接受的，从软件工程的角度，它们会使得代码难以维护。解决这类问题的方法，比较常见的是对实体进行拆分，比如将实体的行为建模成 领域服务 ，像这样：

type People struct {
 vo.IdentityCard
 vo.StudentCard
 vo.WorkCard
 vo.Account
}

type StudentService struct{}
func (s *StudentService) Study(p *entity.People) {
 fmt.Printf("Student %+v studying\\n", p.StudentCard)
}
func (s *StudentService) Exam(p *entity.People) {
 fmt.Printf("Student %+v examing\\n", p.StudentCard)
}

type WorkerService struct{}
func (w *WorkerService) Work(p *entity.People) {
 fmt.Printf("%+v working\\n", p.WorkCard)
 p.Account.Balance++
}
func (w *WorkerService) OffWOrk(p *entity.People) {
 fmt.Printf("%+v getting off work\\n", p.WorkCard)
}

// ...

这种建模方法，解决了上述两个问题，但也变成了所谓的 贫血模型 ：People变成了一个纯粹的数据类，没有任何业务行为。在人的心理上，这样的模型并不能在建立起对现实世界的对应关系，不容易让人理解，因此被学院派所抵制。

到目前为止，贫血模型和充血模型都有各有优缺点，工程派和学院派谁都无法说服对方。接下来，轮到本文的主角出场了。

DCI架构

DCI （Data，Context，Interactive）架构是一种面向对象的软件架构模式，在《The DCI Architecture: A New Vision of Object-Oriented Programming》一文中被首次提出。与传统的面向对象相比，DCI能更好地对数据和行为之间的关系进行建模，从而更容易被人理解。

• Data ，也即数据/领域对象，用来描述系统“是什么”，通常采用DDD中的战术建模来识别当前模型的领域对象，等同于DDD分层架构中的领域层。
• Context ，也即场景，可理解为是系统的Use Case，代表了系统的业务处理流程，等同于DDD分层架构中的应用层。
• Interactive ，也即交互，是DCI相对于传统面向对象的最大发展，它认为我们应该显式地对领域对象（ Object ）在每个业务场景（Context）中扮演（ Cast ）的角色（ Role ）进行建模。 Role代表了领域对象在业务场景中的业务行为（“做什么”），Role之间通过交互完成完整的义务流程 。

这种角色扮演的模型我们并不陌生，在现实的世界里也是随处可见，比如，一个演员可以在这部电影里扮演英雄的角色，也可以在另一部电影里扮演反派的角色。

DCI认为，对Role的建模应该是面向Context的，因为特定的业务行为只有在特定的业务场景下才会有意义。通过对Role的建模，我们就能够将领域对象的方法拆分出去，从而避免了上帝类的出现。最后，领域对象通过组合或继承的方式将Role集成起来，从而具备了扮演角色的能力。

DCI架构一方面通过角色扮演模型使得领域模型易于理解，另一方面通过“ 小类大对象 ”的手法避免了上帝类的问题，从而较好地解决了贫血模型和充血模型之争。另外，将领域对象的行为根据Role拆分之后，模块更加的高内聚、低耦合了。

使用DCI建模

回到前面的案例，使用DCI的建模思路，我们可以将“人”的几种行为按照不同的角色进行划分。吃完、睡觉、玩游戏，是作为人类角色的行为；学习、考试，是作为学生角色的行为；上班、下班，是作为员工角色的行为；购票、游玩，则是作为游玩者角色的行为。“人”在家这个场景中，充当的是人类的角色；在学校这个场景中，充当的是学生的角色；在公司这个场景中，充当的是员工的角色；在公园这个场景中，充当的是游玩者的角色。

需要注意的是，学生、员工、游玩者，这些角色都应该具备人类角色的行为，比如在学校里，学生也需要吃饭。

最后，根据DCI建模出来的模型，应该是这样的：

在DCI模型中，People不再是一个包含众多属性和方法的“上帝类”，这些属性和方法被拆分到多个Role中实现，而People由这些Role组合而成。

另外，School与Company也不再耦合，School只引用了Student，不能调用与Company相关的Worker的Work()和OffWorker()方法。

代码实现DCI模型

DCI建模后的代码目录结构如下；

- context: 场景
  - company.go
  - home.go
  - park.go
  - school.go
- object: 对象
  - people.go
- data: 数据
  - account.go
  - identity_card.go
  - student_card.go
  - work_card.go
- role: 角色
  - enjoyer.go
  - human.go
  - student.go
  - worker.go

从代码目录结构上看，DDD和DCI架构相差并不大，aggregate目录演变成了context目录；vo目录演变成了data目录；entity目录则演变成了object和role目录。

首先，我们实现基础角色Human，Student、Worker、Enjoyer都需要组合它：

package role

// 人类角色
type Human struct {
 data.IdentityCard
 data.Account
}
func (h *Human) Eat() {
 fmt.Printf("%+v eating\\n", h.IdentityCard)
 h.Account.Balance--
}
func (h *Human) Sleep() {
 fmt.Printf("%+v sleeping\\n", h.IdentityCard)
}
func (h *Human) PlayGame() {
 fmt.Printf("%+v playing game\\n", h.IdentityCard)
}

接着，我们再实现其他角色，需要注意的是， Student、Worker、Enjoyer不能直接组合Human ，否则People对象将会有4个Human子对象，与模型不符：

// 错误的实现
type Worker struct {
 Human
}
func (w *Worker) Work() {
 fmt.Printf("%+v working\\n", w.WorkCard)
 w.Balance++
}
...
type People struct {
 Human
 Student
 Worker
 Enjoyer
}
func main() {
 people := People{}
  fmt.Printf("People: %+v", people)
}
// 结果输出, People中有4个Human：
// People: {Human:{} Student:{Human:{}} Worker:{Human:{}} Enjoyer:{Human:{}}}