由于公司技术框架的调整，以及业务的不断扩展，目前存在一些问题。
- 1.微服务框架的推广，导致模块划分过细，一个小的功能点就能划分模块，导致模块量过大。
- 2.api接口大而统一，目前暴露http服务的模块只有一个，所有业务都是通过这一个模块来暴露，虽然有灰度，但是难免会造成问题。
- 3.传统的框架结构存在部分问题，例如：贫血模型只作为数据载体，已经越来越不适用；边界划分不清导致过于分散，容易产生耦合现象等。
因此，在这里对DDD模型进行初探，目标初步解决上述问题，做到高内聚低耦合的效果。
1.技术架构
目前我们大体来说分为api层、module层（包含client和server）
api层通过spring-cloud-alibaba、nacos作为注册中心，通过gateway与客服端进行交互，负责对module层的数据进行编排，当其中需要编排的达到一定量级时，其实已经包含一定的业务逻辑，对外而言，该模块其实也是一个领域服务的概念。在api层的职责划分时，需要参考一定的DDD理念，定义需要包含哪些服务。包含package有controller、enums、model、param四个。
module层通过dubbo、nacos作为注册中心，通过rpc协议与api层以及其他module模块进行交互。负责具体的领域服务功能，富含领域对象，业务逻辑等。
client包含domain（包含充血模型的领域对象用于领域之间交互），enums（定义需要暴露给外部知晓的枚举类），service（定义服务暴露接口）。
service包含impl（处理具体业务逻辑），constant（定义常量和枚举），dao（数据库操作，包含entity数据库实例），respository（定义仓库类，包含cache、db、redis等用户处理缓存以及数据库之间的联系等），infrastructure（定义基础设施，提供一些公共组件以及设计模型等，比如公共方法、策略模式、异常处理、拦截器等等，次数的一些功能点可以考虑迁移到impl中），task（定义定时任务），config（定义配置中心配置，插件配置项等）
以上的框架结构，主要是为了定义各个功能区块，便于后续code review。另外引入部分的DDD理念，期望能够通过领域的划分，来解决目前存在的问题。后续会继续完善DDD在技术框架中的应用。
2.业务架构
目前我们需要对现有的直播购业务进行整合，拆分，以下，对初期的拆分进行讲述。
- 商家领域 主要包含商家管理、分销商管理、代销商管理、客服管理、优惠券管理
- 商品领域 此处由于优惠券等营销领域过小，暂时划分到商品领域。主要包含品类管理、商品管理、库存管理
- 订单领域 处理订单的流转，此处包含各种状态机
- 物流领域 通过监听订单发货、退货等事件，进行物流处理
-资产领域 用户余额管理 通过监听订单的变化事件，来处理对应的余额流水变化。 - 外部领域 对接外部领域，包括内网和外网
商家领域对商品领域内的各类商品、优惠券进行处理。
订单领域的下单影响商品领域库存，退货也影响商品领域库存
写在最后
为了解决历史遗留问题，利用上述架构模型，将原有分散的功能点，通过领域模型进行整合，以减少对应的模块量以及分散的功能点。
通过领域的划分，将原有大而统一的api进行拆分，按照领域的能力进行拆分。
通过引入DDD，将原有暴露的接口更加丰富的功能，划分号业务领域，以独立各种的能力，对应开发时，也不用进行耦合，做到高内聚低耦合的目的。
后续希望能够更加 深入DDD，引入中台概念来完善模块。
鉴于作者经验有限，我们对领域驱动的理解难免会有不足之处，欢迎大家共同探讨，共同提高。
网友评论