架构设计师为了解决软件复杂度,要识别出系统复杂点,然后针对复杂点进行设计
ob 大叔在 2012 年的一篇博文 The Clean Architecture 中提出了一种适用于复杂业务系统的软件架构方式。在干净架构出现之前,已经有一些其它架构,包括 Hexagonal Architecture、Onion Architecture、Screaming Architecture、DCI和 BCE。这些架构在本质上都是类似的,都采用分层的方式来达到一个共同的目标,那就是分离关注。
微服务中应该首先建立UL(Ubiquitous Language,通用语言),然后再讨论领域模型。
一个微服务最大不要超过一个BC(Bounded Context,限界上下文),否则微服务内会存在有歧义的领域概念。
一个微服务最小不要小于一个聚合,否则会引入分布式事务的复杂度。
微服务的划分过程类似于BC的划分过程,每个微服务都有一个领域模型。
微服务间的集成可以通过Context Map来完成,比如ACL(Anticorruption Layer,防腐层)。
微服务间最好采用Domain Event(领域事件)来进行交互,使得微服务可以保持松耦合。
DCI架构(Data、Context和Interactive三层架构)
Data层描述系统有哪些领域概念及其之间的关系,该层专注于领域对象的确立和这些对象的生命周期管理及关系,让程序员站在对象的角度思考系统,从而让“系统是什么”更容易被理解。
Context层:是尽可能薄的一层。Context往往被实现得无状态,只是找到合适的role,让role交互起来完成业务逻辑即可。但是简单并不代表不重要,显示化context层正是为人去理解软件业务流程提供切入点和主线。
Interactive层主要体现在对role的建模,role是每个context中复杂的业务逻辑的真正执行者,体现“系统做什么”。role所做的是对行为进行建模,它联接了context和领域对象。由于系统的行为是复杂且多变的,role使得系统将稳定的领域模型层和多变的系统行为层进行了分离,由role专注于对系统行为进行建模。该层往往关注于系统的可扩展性,更加贴近于软件工程实践,在面向对象中更多的是以类的视角进行思考设计。
DCI目前广泛被看作是对DDD的一种发展和补充,用在基于面向对象的领域建模上。显式的对role进行建模,解决了面向对象建模中的充血模型和贫血模型之争。DCI通过显式的用role对行为进行建模,同时让role在context中可以和对应的领域对象进行绑定(cast),从而既解决了数据边界和行为边界不一致的问题,也解决了领域对象中数据和行为高内聚低耦合的问题。
算法及角色-对象映射由Context拥有。Context“知道”在当前用例中应该找哪个对象去充当实际的演员,然后负责把对象“cast”成场景中的相应角色。可以避免对象贫血
有一种方法可以改进分层架构,即依赖倒置原则(Dependency Inversion Principle, DIP),它通过改变不同层之间的依赖关系达到改进目的。
https://www.jianshu.com/p/a775836c7e25
https://github.com/agiledragon/transfer-money
https://blog.jaggerwang.net/clean-architecture-in-practice/
https://time.geekbang.org/column/article/158248
https://insights.thoughtworks.cn/from-sandwich-to-hexagon/