领域驱动与微服务落地实战-领域划分和建模

领域划分-战略设计

软件研发好比行军作战，领域划分则属于战略设计，影响整体大局。
现代软件研发大部分都是迭代研发，整体的领域划分也会随着迭代调整，是一个演变过程，贯穿整个研发周期。
如何做领域划分，有以下几个原则

水平划分

水平划分是基于业务层级，受应用架构的影响，一般会分 接入层（网关层），服务层，基础层。
水平层级的依赖一般是单向的，即上层依赖下层。

接入层（网关层）

直接提供给外网访问数据，一般对接app或者h5，处理鉴权等。

服务层

提供具体业务服务能力，一般不对外，只提供soa接口，业务变更频繁，迭代快

基础层

具体业务服务依赖的一些通用服务，例如统一账户服务等，业务相对稳定，迭代慢

垂直划分

垂直划分，是基于一个水平层级能，基于细分业务领域拆分，例如原来商品和商户在一个业务服务，后面随着
业务发展，拆成2个独立的垂直业务服务。垂直划分的服务依赖可以是双向，最终在同一个水平层级内不同的垂直服务的
依赖关系会发展成网状，这个会增大服务治理的难度。

非功能性拆分

非功能性拆分，一般有to B/to C拆分，实时/离线拆分

to B/to C 拆分

常见于cqrs风格架构，b/c两边的性能要求不一致，迭代频率不一致，稳定性保障不一致等导致切分服务

离线/实时 拆分

离线/实时场景下，大部分采用的技术栈不一样，语言不一样，虽然多语言应用在微服务里也是可行的，但为了简化研发和维护成本，一般还是拆分。

如何做领域划分

这个是一个没有标准答案的问题，仁者见仁，智者见智。以上几个原则是做划分时的一个主要参考。划分也不是一锤子买卖，
所有的抽象都是建立在已知用例上，业务会变，会新增用例，当新增用例无法套到现有的领域划分里面，就需要调整领域划分。

领域建模-战术设计

领域划分解决了战略设计问题，那么领域建模则是具体的战术设计。领域建模是面向对象分析的方法论，
它可以利用面向对象的特性（封装、多态，继承）有效地化解复杂性。区别于传统的面向数据模型建模（er图），
领域建模是以对象模型为中心，建模过程就是面向对象分析过程，具体的建模过程，建议使用uml来辅助建模，常见的
uml建模图有以下几种

用例图

用例图是基于场景的模型，描述了人员使用该软件系统做了什么，是需求功能的直观抽象

类图

类图描述了领域模型核心属性和功能，并体现了面向对象的特性（继承，封装，多态）

流程图

流程图描述了业务流程的节点，和相关流转

时序图

时序图细化某个用例的具体实现，体现在该场景下不同应用节点之间的交互时序

架构图

体现服务应用之间的层级，业务边界，依赖关系，支撑领域划分

附录书籍

• 《UML面向对象分析与设计》
• 《领域驱动设计：软件核心复杂性应对之道》