领域驱动实践-从需求到代码

toby1024

业务需求

网约车出行项目mvp

  • 作为乘客我希望创建⼀个出⾏订单,以便于从A地前往B地
  • 作为司机我希望履⾏⼀个订单,以便于获取收⼊
  • 作为运营我希望能取消订单,以便于乘客联系不上司机时重新下单

传统mvc模式

传统mvc往往基于数据模型进行开发,通过需求分析,确定数据模型,然后在数据模型上做CRUD开发

image
server类中聚集类所有的业务代码

image

所有的操作都是在操作数据,当业务变得越来越复杂时,service中的代码越来越臃肿,然后根据业务进行模块拆分,但是由于业务纵横交错,后续修改业务代码时,可能会需要修改多个模块。

微服务开发

微服务的出现一部分原因就是希望将业务划分清楚,解决模块耦合的问题,借助领域驱动设计,我们可以通过一些方法论来进行业务建模和微服务划分。

统一语言

针对不同的角色,同一个事务可能有不同定义。

  • 对于乘客来说,出行订单应该是一个行程。乘客关心的是起点,终点,司机的实时位置,需要支出的费用。
  • 对于设计来说,出行订单是一笔生意。司机关心的是乘客的位置,目的地,该笔行程的收入、奖励。
  • 对于运营人员来说,出行订单是一个合约,合约的双方是乘客和司机,运营人员关注合约的履约情况,合约的抽成信息等。

针对不同的参与角色,我们定义不同的模型概念。
image

通过对业务进行限界上下文划分,很容易就可以进行代码的隔离,不同的上下文分开进行编码,上下文之间的业务调用通过api接口方式进行交互,这样后续的业务演进,系统部署升级以及扩容都相对独立。

但是一个userstor就划分一个微服务肯定是不现实的,我们需要根据业务的相关性来进行,从两个方向来进行组织限界上下文。

语义相关性

不同的用例存在语义相关性就可以考虑放在一个限界上线文内。例如创建行程,取消行程都跟行程有关,就适合放在一个限界上下文来处理。

功能相关性

有些用例虽然都是操作相同的对象,但是在功能上有相互的独立性,应该考虑分割成独立的上下文。例如支付行程,虽然也是在操作行程对象,但其实更侧重于支付动作,后续的业务扩展也多围绕在支付上,如增加支付渠道,增加租金统计等和行程关联不大。

DEMO

代码参考:ddd-demo
image

阅读 88

奔波~儿爸

1 声望
1 粉丝
0 条评论

奔波~儿爸

1 声望
1 粉丝
宣传栏