DDD系列-如何判断要不要使用DDD

如何判断要不要使用DDD

当我们介绍业务背景的时候，一定要足够复杂，才可能继续讨论DDD如何解决这种复杂度的。如果是一个掷骰子游戏，那肯定不会用DDD去实现，这种例子只帮你理解一些概念。

这里参考尤达老师的零售项目，整个背景可以用下面一张图表示

1）运营人员通过电脑操作投放售卖机

2）用户通过手机支付的方式购买商品

3）安装人员按照安装单到指定地点安装售卖机

4）商务会去各商场洽谈合作售卖机事宜

5）配送人员必须及时按照配送单补充售卖机商品

一个智能零售主要包含以上功能，注意，这里不包含细节，但是所有的角色都在里面，需要讨论每个细节的时候，会再次深入到内部。比如你需要考虑购买问题的时候，用户是使用微信，支付宝，或者硬币支付，或者小程序会员的方式进行购买，再或者，这里搞打折活动......

 以及同理，下面是一个简化的在线医院系统，目的是让用户足不出户即可达到看病的目的

这个系统也很复杂，模拟了一套线下看病的流程

1）用户在手机上输入足迹的病情，类似去医院对着窗口说自己感冒嗓子疼

2）助手，类似那个窗口给你挂号的，会告你去什么科室看病，这里直接是指派给一名医生了，简化了一下

3）医生，医生进行接诊操作，类似现实中你坐到了医生的对面，然后就行一些谈话

4）医生给你开局药品清淡，然后你进行线上支付，来购买药品

5）药品配送人员会将这些药品送到你的家门口

整个系统是极其复杂的，任何一个环节拿出来都可以构成一个小系统，比如开药的环节，就会引入处方药和非处方药等领域的概念，另外他们也需要处理监管的问题

总结，以上两种情况都非常适合使用DDD，理由是他们足够复杂，并且相应的现实世界已经有一套成熟的模型，软件开发人员必须亲自搞懂现实中的这些系统是如何运作的，它们的关系是怎样的，然后将这一套模型映射到我们的软件系统中。

我们通常说代码尽量不要复用，软件模型也是同样的道理，现实生活中有的模型尽量参考，改进，避免盲目创建出一个毫不相干的新模型。