上面一个图适合所有的需求拿到手以后该想哪些问题或者问哪些问题。因为有的时候你从老板或者产品经理那只是拿到
一个大概的需求比如 开发一个网上叫车的系统,系统自动分配离客户最近的司机。
一、业务领域
1. 业务子域
那么要分三个业务子域.
身份认证子域 (这应该是所有系统都有的)
打车管理子域(核心业务子域)
报表子域(这也应该是所有系统都有的)
确定业务子域后,就要定义每个业务子域的业务术语。形成开发和业务人员通用的沟通话术。
以打车管理子域为例
2. 业务术语表
业务规则：
打车：经认证的用户，打开叫车应用，首先会定位，会在地图上显示附近的汽车。用户发起叫车后，系统会自动通知离客户最近的司机。用户到达目的地后，系统自动从用户关联的账户扣款。
分配司机：系统为用户分配一个最近的司机
计费：系统根据用户所乘车的当前位置进行计费
扣款申请：用户到达目的地后，系统根据路程的长远向用户的银行账户发送扣款申请
打车管理子域依赖于身份认证子领域。只用经过认证的用户和司机才可以使用打车管理App，只有有足够信用额度的用户才可以打车。运营报表依赖于打车管理子领域，运营报表目前仅需要从打车管理里提取用户的消费记录，后面估计还会有其它需求。
业务对象：
以打车管理限界上下文，分析参与者
在打车管理限界上下文里，有两个明显的角色：用户和司机
用户：在打车App有有效的账号，有足够的信用，叫车时要有精确的位置
司机：需要在打车App上注册的，有有效的身份证明和驾驶证，无不良记录。收到用户的订单后，将用户从起始点安全地送到目的地。
细致分析后，我们发现还有一个隐式的对象：订单。从业务来看，最终的目的还是为了多拿订单，从这个角度来看，订单是比比用户和司机都重要的业务对象。
业务状态：
以打车管理限界上下文，分析业务状态
用户已叫车、用户已上车、用户已到达
二、模型空间
1. 战略建模：
身份认证限界上下文、打车管理限界上下文、运营报表限界上下文
2. 战术建模：
聚合：
订单：是业务的真正关注点。订单的根实体是订单本身、本次计费总额，值对象为用户的路途（起始位置、终止位置），关联的实体包括用户和司机。
用户：对于用户，在打车管理这个限界上下文里，我们只关注用户的ID、银行账户。根实体是用户，关联实体是银行账户，包括账号、银行名称。用户会发起叫车的事件。
司机:在打车管理限界上下文里，我们关注的是司机的id，车牌号及司机当前位置。司机当前位置为值对象。用户上车后，司机会发出用户已上车的信号。到达终点时，司机会发起已到达的事件
领域服务：
用户定位服务：用户打开打车App时，会自动启动定位服务，并显示周围的司机
分配司机服务：收到用户叫车的消息后，为用户分配一个最近的司机
计费管理服务：用户上车后，会实时搜集司机当前位置，并实时计费。当收到已到达终点的信号时，自动向用户管理账号发起扣款申请。
领域事件：
用户已叫车事件：由用户发起
用户已上车事件：由司机发起
用户已到达事件：由司机发起
三、微服务设计
1. 打车管理微服务的设计
微服务里的微并不是越小越好。微服务和分布式架构是相关联的。分布式架构第一原则是能不做分布式就不要分布式，对于微服务，是在能满足业务需求的情况下，尽可能的不微。所以，对于新的需求，微服务的粒度可以和限界上下文一对一映射。当需求逐渐明晰了后，如果业务需要，微服务的最小粒度可以放到聚合的级别。
因为是创业公司，对很对需求了解都还不够细，我们微服务粒度和限界上下文对应，现有的版本是V1.0
2. 聚合的设计
3. 领域服务的设计
4. 领域事件
5. 资源库
定义订单资源库类OrderRepository。OrderReporsitory接口目前定义一种方法：findByUserID，返回和该ID相关联的用户的所有订单
OrderRepository基于Repository接口。在Repository接口里定义三种方法：add、remove、update。用来增加、删除、更新订单
四、总结
DDD并不是一个新的架构方法，它在微服务概念提出之前就已经出现了。微服务概念提出后，大家都认为很好，但是对于如何设计微服务当时没有给出一个很好的方法，后来，大家套用了DDD的理念来设计微服务，发现这种方法是可行的，DDD的很多理念也和微服务是一致的。