共计 876 个字符，预计需要花费 3 分钟才能阅读完成。
业务需要
网约车出行我的项目 mvp
- 作为乘客我心愿创立⼀个出⾏订单，以便于从 A 地返回 B 地
- 作为司机我心愿履⾏⼀个订单，以便于获取收⼊
- 作为经营我心愿能勾销订单，以便于乘客分割不上司机时从新下单
传统 mvc 模式
传统 mvc 往往基于数据模型进行开发，通过需要剖析，确定数据模型，而后在数据模型上做 CRUD 开发
image
server 类中汇集类所有的业务代码
所有的操作都是在操作数据，当业务变得越来越简单时，service 中的代码越来越臃肿，而后依据业务进行模块拆分，然而因为业务犬牙交错，后续批改业务代码时，可能会须要批改多个模块。
微服务开发
微服务的呈现一部分起因就是心愿将业务划分分明，解决模块耦合的问题，借助畛域驱动设计，咱们能够通过一些方法论来进行业务建模和微服务划分。
对立语言
针对不同的角色，同一个事务可能有不同定义。
- 对于乘客来说，出行订单应该是一个行程。乘客关怀的是终点，起点，司机的实时地位，须要收入的费用。
- 对于设计来说，出行订单是一笔生意。司机关怀的是乘客的地位，目的地，该笔行程的支出、处分。
- 对于经营人员来说，出行订单是一个合约，合约的单方是乘客和司机，经营人员关注合约的履约状况，合约的抽成信息等。
针对不同的参加角色，咱们定义不同的模型概念。
通过对业务进行限界上下文划分，很容易就能够进行代码的隔离，不同的上下文离开进行编码，上下文之间的业务调用通过 api 接口方式进行交互，这样后续的业务演进，零碎部署降级以及扩容都绝对独立。
然而一个 userstor 就划分一个微服务必定是不事实的，咱们须要依据业务的相关性来进行，从两个方向来进行组织限界上下文。
语义相关性
不同的用例存在语义相关性就能够思考放在一个限界上线文内。例如创立行程，勾销行程都跟行程无关，就适宜放在一个限界上下文来解决。
性能相关性
有些用例尽管都是操作雷同的对象，然而在性能上有互相的独立性，应该思考宰割成独立的上下文。例如领取行程，尽管也是在操作行程对象，但其实更侧重于领取动作，后续的业务扩大也多围绕在领取上，如减少领取渠道，减少租金统计等和行程关联不大。
DEMO
代码参考：ddd-demo
正文完
