架构师训练营第十周作业
根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图。
关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?
组件设计原则
组件设计原则包括:共同封闭原则、共同重用原则、重用发布等价原则、无循环依赖原则、稳定依赖原则、抽象依赖原则。
这些原则是 SOLID 原则在组件粒度上的应用,可以帮助我们判断组件的划分、组件之间的依赖是否合理。我们在分析、验证一个设计方案时,这些原则应该作为我们评审的 checklist 的一部分。
和 SOLID 原则类似,我们无法直接从这些原则获得线索,获得需要的拆分结构。我们从需求开始设计架构时,架构模式、领域模型才是我们的主要抓手。
领域驱动设计
领域驱动设计包括战术设计和战略设计。战略设计主要是确定子域和边界上下文,定义边界上下文之间的关系;战术设计则主要包括:根据业务领域建模;在代码层面有效实现领域模型,将领域模型同技术解耦。
目前的 DDD 在战术层面是完备的,可操作的。它确实带来了 DDD 宣称的好处:分析、设计和实现时,以统一的方式(领域模型)呈现业务逻辑。我个人一直坚持领域建模,以模型指导编码,这种开发模型一个明显的好处就是大大提高了代码的可测试性。
但是在战略层面,DDD 定义了子域、边界上下文,阐述了为什么要合理的子域和上下文,给出了一些实现上下文交互的原则。但可惜这些内容还远远不够。子域、上下文和具体的编码实现相比,意义更重大,难度也更高,要得到它们,需要进行业务建模、需求分析以及架构设计多个软件工程活动,而要有效开展这些活动,作为开发人员,需要得到一个系统性的指导,说明 who、when、what、why 和 how 的问题。我觉得在这些方面,其他一些专门讲述需求管理、软件架构的书籍和资料的价值更大。
中台架构
我认为中台架构和软件架构属于不同层面的架构。
软件架构是指对一个边界确定的软件系统进行分解、得到其内部结构。对一个企业或者组织来说,这个软件系统和其他的软件系统互相交互,共同承担企业对客户的价值。
和软件架构相比,中台架构不是针对特定系统,而是回答企业包含哪些系统,这些系统之间的关系等问题。要得到中台架构,我们需要把整个企业、整个业务作为研究对象。
中台架构属于企业架构范畴,虽然有些通用的原则(比如:高内聚、低耦合)对企业架构和软件架构都适合,但是企业架构有另外一套方法论,比如:TOGAF。
评论