## 启迪
限界上下文也就是微服务的边界，也可以理解为微服务，一个限界上下文=一个微服务。
个人理解领域驱动设计就是微服务驱动设计，从战略上先进行微服务的划分，从战术上针对某个微服务进行领域模型的设计也就是业务模型的设计。
领域模型包括：
- 实体
- 值对象
- 聚合
- 领域服务
- 领域事件
- 资源库
- 应用服务
## 什么是领域驱动设计?
理解领域驱动设计是什么之前，我们先来理解下什么是领域？
领域可以理解为业务，领域专家就是对业务很了解的人。
领域驱动设计的核心就是和最了解业务的人也就是领域专家一起通过领域建模的方式去设计我们的软件程序。
- 那么领域如何驱动设计？或者说业务如何驱动设计？
传统开发过程我们都是基于面向数据开发，拿到产品原型脑海里想着都是应该创建哪些表和哪些字段才能满足需求。
而领域驱动设计开发过程是让我们基于面向业务开发、面向领域模型开发。
领域模型的核心是通过承载和保存领域知识，并通过模型与代码的映射将这些领域知识保存在程序代码中，
在传统开发中，当业务被转换为一张张数据表时，丢失最多的就是领域知识(领域知识也就是我们在模型中定义的一些业务逻辑行为)。
面向领域模型开发的优点：
- 存储方便，统一使用JSON进行存储。
>例：
>订单领域包含基础信息、商品信息、金额信息、支付信息等包含订单全生命周期的子域，
>对于传统面向数据的开发模式我们需要创建N张表进行存储订单的信息，但是面向领域开发时我们
>可以通过利用nosql数据库(mongo、es等)进行保存整个订单域的信息，提高查询、更新效率，简化代码
- 复用性高，引用某个领域模型，就可以拥有该领域模型的所有行为。
>例：
>基于微服务架构下，某个电商应用需要一个判断某个订单是否是在线支付订单的逻辑时，
>对于传统的开发模式我们需要调用订单中心的服务查询订单信息，然后写一个判断是否在线支付订单的方法。
>如果有多个应用都需要这个逻辑时，每个应该都需要重复写相同的方法。
>但面向领域开发时，只需要引用订单中心的jar包，然后统一调用订单领域内的方法即可。
>这样就实现了业务的高内聚
## DDD可以做什么
DDD主要分为两个部分，战略设计与战术设计
- 战略设计
- 围绕微服务拆分
- 战术设计
- 微服务内部设计
## DDD怎么做
- 战略设计
- 和领域专家一起通过(过往经验、事物联系、事件风暴等)划分【限界上下文】
>限界上下文也就是微服务的边界，也可以理解为微服务。
>一个限界上下文=一个微服务
- 战术设计
- 开发人员通过(领域模型)保存【领域知识】
>领域知识也就是事物(角色)、行为(规则)和关系
>
## DDD领域模型
领域模型包含什么？
- 实体
>具有唯一标识，包含着业务知识的【充血模型】对象，用于对唯一性事物进行建模。
>例：
>```
>public class Order {
>private long orderId
>private OrderAmount amount
>private List item
>}
>```
- 值对象
>生成后即不可变对象，通常作为实体的属性，用于描述领域中的事物的某种特征。
>例：
>```
>public class OrderItem {
>private long orderId
>private String productCode
>private String productName
>}
>```
- 聚合
>将实体和值对象在一致性边界之内组成聚合，使用聚合划分微服务(限界上下文)内部的边界
- 领域服务
>分担实体的功能，承接部分业务逻辑，做一些实体不变处理的业务流程。不是必须的
>主要承接内部领域服务调用和外部微服务调用，及一些聚合业务逻辑处理。
>例：
>```
>@Service
>public class ShoppingcartDomainService {
>private final ShoppingcartRepository shoppingcartRepository
>private final ProductFacade productFacade
>private final UserFacade userFacade
>private final PromotionFacade promotionFacade
>
>
>// 1.查询购物车信息
>ShoppingcartDO entity = shoppingcartRepository.loadShoppingcart(userId)
>
>// 2.调用【用户中心】服务查询用户信息
>User user = userFacade.getUser(userId)
>
>// 3.调用【商品中心】服务查询商品信息
>Product product = productFacade.getProduct(productCode)
>
>// 4.调用【活动中心】服务查询活动信息
>Promotion promotion = promotionFacade.getPromotionByProductCode(productCode)
>
>// 5.创建购物车实体
>Shoppingcart shoppingcart = new Shoppingcart(entity.getId, user, product, promotion)
>
>// 6.购物车按活动分组
>shoppingcart.groupby4Promotion()
>}
>```
>
>
- 领域事件
>表示领域中发生的事情，通过领域事件可以实现本地微服务(限界上下文)内的信息同步，同时也可以实现对外部系统的解耦
- 资源库
>保存聚合的地方，将聚合实例存放在资源库(Repository)中，之后再通过该资源库来获取相同的实例。
>
- 应用服务
>应用服务负责流程编排，它将要实现的功能委托给一个或多个领域服务来实现，
>本身只负责处理业务用例的执行顺序以及结果的拼装同时也可以在应用服务做些权限验证等工作。
>
DDD是告诉我们如何做好业务层！并以领域驱动设计思想来选择合适的框架。
我们知道软件的产生过程是：分析、设计、编程、测试、部署。过去，分析领域和软件设计是分裂的，分析人员从领域中收集基本概念；而设计必须指明一组能在项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题。 模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。
DDD(Domain-DrivenDesign领域驱动设计)
2004年著名建模专家EricEvans发表了他最具影响力的著名书籍：Domain-DrivenDesign–TacklingComplexityintheHeartofSoftware（中文译名：领域驱动设计 2006年3月清华出版社译本，或称DomainDriven-Designarchitecture[EvansDDD]）。时值今日，DDD开发框架已经层出不穷（如RoR、RIFE、JdonFramework等），我们项目软件包结构都变成了这样：xxx.modelxxx.service，DDD思想可以说是遍地开花了.领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道.
模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计，会编程。
DDD的意思是领域驱动设计，是domain driven design的缩写。
一、读音
英 [dəˈmeɪn ˈdrɪvn dɪˈzaɪn]，美 [doʊˈmeɪn ˈdrɪvn dɪˈzaɪn]。
二、domain释义
领域，范围，范畴。
三、driven释义
驱动，驾驶，开车。
四、design释义
设计，布局，安排。
五、示例
He is mostly interested inDomain Driven Design and Aspect Oriented Programming.
他感兴趣的领域包括领域驱动设计以及面向方面的编程。
扩展资料
domain driven design的相关词语—Event Driven Architecture：
一、释义
事件驱动架构。
二、读音
英 [ɪˈvent ˈdrɪvn ˈɑːkɪtektʃə(r)]，美 [ɪˈvent ˈdrɪvn ˈɑːrkɪtektʃər]。
三、Architecture释义
体系结构，总体、层次结构。
四、示例
Staged Priority Event Driven Architecture Oriented to Service Integration ResourceConsumption in Web Service Bus.
面向Web服务总线集成的分阶段优先级事件驱动架构。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）