如何实现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:{}}}
富士康否认大举裁员 机器人成制造业升级趋势
制裁取消了：中兴与美国达成和解协议
帮你看懂已经全面攻占iPhone的FinFET
磁带或将会成为未来储存数据的载体
Silicon Labs中国团队扩大招揽物联网专才
如何实现DCI架构（中）
美国半导体协会副总裁解读国际技术路线图
功率放大器在介电弹性体中的应用：电子皮肤也能自主愈合？什么原理？
温度测量系统中高精度ADC设计详解
财经速览：快手总营收811亿 趣睡科技IPO拟募资8亿
浅谈CM CANopenS7-1200 PLC的CANopen连接
爱立信与M1联合部署新一代5G路由器，打造面向未来的移动传输网
数字中国指数报告（2020）
LED照明行业中存在的问题
Marvell收购 Aquantia,为自动驾驶网络芯片提前布局
轴流风机离心风机的区别是什么，如何区分
英特尔首席架构师晒出几款英特尔独显，GPU已经在生产中
如何选择路由器？路由器是如何工作的？
过流继电器安装方法和环境要求
京东与腾讯宣布：将联合推出赋能品牌商的“京腾无界零售”解决方案
问题一：上帝类
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:{}}}
富士康否认大举裁员 机器人成制造业升级趋势
制裁取消了：中兴与美国达成和解协议
帮你看懂已经全面攻占iPhone的FinFET
磁带或将会成为未来储存数据的载体
Silicon Labs中国团队扩大招揽物联网专才
如何实现DCI架构（中）
美国半导体协会副总裁解读国际技术路线图
功率放大器在介电弹性体中的应用：电子皮肤也能自主愈合？什么原理？
温度测量系统中高精度ADC设计详解
财经速览：快手总营收811亿 趣睡科技IPO拟募资8亿
浅谈CM CANopenS7-1200 PLC的CANopen连接
爱立信与M1联合部署新一代5G路由器，打造面向未来的移动传输网
数字中国指数报告（2020）
LED照明行业中存在的问题
Marvell收购 Aquantia,为自动驾驶网络芯片提前布局
轴流风机离心风机的区别是什么，如何区分
英特尔首席架构师晒出几款英特尔独显，GPU已经在生产中
如何选择路由器？路由器是如何工作的？
过流继电器安装方法和环境要求
京东与腾讯宣布：将联合推出赋能品牌商的“京腾无界零售”解决方案