领域驱动开发分享
2018-09-14 18:39:56摘要：前言 微服务已经成为目前开发的主流设计，我们也要与时俱进不能一直还停留在三层架构的思想层面。年前也更大家简单介绍过什么是微服务，以及实现微服务中需要用到的一些相关技术。之前一直停留在工具和代码阶段，那具体应该如何设计如何落地呢？微服务设计过程中往往会面临边界如何划定的问题，微服务到底应该拆多小，不同的人会根据自己对微服务的理解而拆分出不同的微服务，如何我们还是不经过设计，只是靠拍脑袋硬完成开发的话，上线后运维的压力将会远大于单体程序。那是否有合适的理论或设计方法来指导微服务设计呢？答案就是DDD。微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了. 2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。利用 DDD 设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。于是越来越多的人开始把 DDD 作为微服务设计的指导思想。现在，很多大型互联网企业已经将 DDD 设计方法作为微服务的主流设计方法了。DDD 也从过去“雷声大，雨点小”，开始真正火爆起来。 DDD知识体系 领域 领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。 核心域：系统最核心并有复杂业务逻辑的业务界限上下文，比如OA系统的物资管理。 支撑域：系统支撑其他界限上下文的基础，比如OA系统的员工基础资料。 通用域：需要使用的基础框架或第三方成熟解决方案，比如OA系统工作流引擎。 工作流引擎是个比较大的领域，目前我们…… 阅读全文
