DailyMart02：DDD领域分解与微服务划分

大家好，今天咱们继续更新DDD&微服务系列！

DailyMart是一个简单的购物商城，主要销售书籍，包括实体书和电子书。本文将使用领域驱动设计（DDD）对DailyMart的业务进行分析与优化，以提高系统的内聚性和降低耦合度。

1. DailyMart核心业务流程

DailyMart的核心业务流程如下：

1. 用户在DailyMart上注册并获得初始积分。购物时可获得积分奖励，1000积分可抵扣10元。
2. 用户可配置多个收货地址，将其中一个地址设为默认地址。
3. 用户登录后可将书籍加入购物车或直接购买。购买后生成订单并支付。支付完成后，商城发货，用户可查看物流信息。

2. 领域分解与子域划分

根据DDD的设计原则，我们首先对DailyMart进行领域分解，识别出核心业务和支撑业务。

2.1 什么是领域

在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型。进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。

既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。

领域可以进一步划分为子域，每个子域对应一个更小的问题域或更小的业务范围，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。

核心域是系统的核心业务，直接关系到业务价值；支撑域是辅助核心域的业务，对核心域有一定的支持作用；通用域是通用的业务功能，可以在多个系统中复用。

划分核心域、通用域、支撑域的原因是公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略。对于核心域我们需要重点关注，投入足够的资源，需要掌握；对于支撑域和通用域在资源不够的情况下可以采用外包或外采的方式。

2.2 DailyMart的领域分解

在对DailyMart进行领域拆分时，首先我们需要识别出系统中具有业务价值的部分，将其划分为核心域。

很显然，对于一个商城系统来说自然是卖更多的商品，获得更多的收入。在DailyMart中商品和订单是直接关系到业务收入的部分，因此将其划分为核心域。

确定好核心域后，我们再根据DailyMart的业务流程找出其他支撑业务，包括用户管理、积分管理、收货地址管理、购物车管理和物流管理。在将支撑业务划分子域时需要考虑各个业务功能之间的关联程度，关联性较高的功能应该归属于同一个领域，以便于协同开发和维护。 在DailyMart中用户管理、积分管理和收货地址管理都与用户相关，因此将它们划分到用户子域；购物车管理和物流管理功能比较独立，可以划分成单独的子域。

综上，我们将DailyMart中商品子域、订单子域、用户子域、购物车子域和物流子域5个主要子域。

3. 限界上下文划分

在DailyMart的领域划分中，我们已经识别出了商品子域、订单子域、用户子域、购物车子域和物流子域这几个主要的子域，接下来需要需要进一步将每个领域划分为若干限界上下文（Bounded Context）。

3.1 什么是限界上下文

限界上下文是DDD中的一个重要概念，它定义了领域知识和语言的范围。每个限界上下文都有自己的领域模型，相互之间通过定义良好的API进行协同。限界上下文的划分主要依据领域模型之间的干扰程度，领域模型之间互不干扰的部分可以划分为独立的限界上下文。

可以说，限界上下文是微服务设计和拆分的主要依据。在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。

不过，这里要提示一下：除了理论，微服务的拆分还是有很多限制因素的，在设计中不宜过度拆分。

3.2 DailyMart的限界上下文

在DailyMart中，每个子域内部的业务逻辑和数据模型都较为独立,但是子域之间又存在一定的关联,这就可能会导致子域的领域模型之间相互干扰。为了减少领域模型之间的干扰,我们需要对每个子域内部进一步划分限界上下文。

商品子域主要包括商品信息管理和商品库存管理两个方面，这两个方面的数据模型和业务逻辑都较为独立，可以将其划分为商品信息限界上下文和商品库存限界上下文。

订单子域涉及订单创建、支付、发货等流程，这些流程关联紧密，不单独划分限界上下文。

用户子域主要包括用户注册、登录、积分管理和收货地址管理，其中登录注册，收货地址管理跟用户密切相关，积分管理主要是记录用户购物行为带来的积分变化和积分使用情况，也可以放入用户上下文统一管理。

购物车子域和物流子域内部的业务比较独立,暂不需要进一步划分限界上下文。

终划分的限界上下文如下：

综上,我们将DailyMart划分为6个主要的限界上下文，它们之间通过接口进行交互和协同工作。这有助于我们在后续的领域建模和开发中保持高内聚和低耦合。

4. 微服务拆分

如前所述，一个限界上下文可以被设计为一个微服务。因此，我们将以下几个限界上下文设计为微服务

• 商品微服务：dailymart-product-service
• 库存微服务：dailymart-inventory-service
• 用户微服务：dailymart-customer-service
• 订单微服务：dailymart-order-service
• 购物车微服务：dailymart-car-service
• 物流微服务：dailymart-logistics-service

每个微服务都有自己的存储，它们之间通过API进行交互。下面是使用Spring Cloud组件的微服务架构图（不考虑其他中间件）。

使用IDEA生成的项目结构如下：

5. 小结

本文主要是DailyMart的业务分析，同时通过DDD战略设计进行领域分解、限界上下文划分，同时根据限界上下文划分出了微服务架构，提高了系统内聚性和降低了耦合度。