利用Spring Cloud实现微服务（三）- 业务领域驱动微服
虚拟一家类似于XX打车的创业公司，要开展业务，首先要开发一套网上叫车的系统。使用DDD的思想进行设计，并用SpringCloud框架进行开发。本节主要讲如何通过业务领域驱动微服务的设计
公司名称：打车易公司
公司愿景：让天下没有难打的车
一、业务领域
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的很多理念也和微服务是一致的。
本文中的举例，对业务的理解不一定到位，我也相信会有更好的模型，领域事件的设计也偷懒了，请大家多多指教。
下一节，我们会基于目前的设计，利用Spring Cloud框架开发叫车管理微服务。
