云世 公众号
当大家看到贫血模型、充血模型、策略模式、装饰者模式时,发出这样的感慨:“难道这就是 DDD 吗?和我们平时的开发没有什么不同啊。”殊不知,其实你还没有 Get 到 DDD 的真谛 。。
DDD的真谛
什么是 DDD 的真谛呢?那就是领域建模,它改变了我们过去对软件开发的认知。如图 1 所示,DDD 的精髓是:
-
首先深刻理解业务;
-
然后将我们对业务的理解绘制成领域模型;
-
再通过领域模型指导数据库和程序的设计。
图 1 领域驱动设计的真谛
过去,我们认为软件就是,用户怎么提需求,软件就怎么开发。这种开发模式使得我们对需求的认知浅薄,不得不随着用户的需求变动反复地改来改去,导致我们很累而用户还不满意,软件研发风险巨大。
正是 DDD 改变了这一切,它要求我们更加主动地去理解业务,掌握业务领域知识。这样,我们对业务的理解越深刻,开发出来的产品就越专业,那么客户就越喜欢购买和使用我们的产品。
然而,真实世界是非常复杂的,这就决定了我们不可能一开始就深刻理解业务。起初,我们对业务的理解浅薄,基于它做出来的领域模型也是浅薄的,导致最后开发出来的软件虽然也能用,但用户并不一定满意。然而,如果我们不断地与客户沟通,深入地理解业务,听取他们的意见,我们对业务的理解就会越来越深刻、越来越准确。再结合我们的专业技术知识,就能够理解我们的软件需要解决客户的什么问题,怎样做才是最优,怎样做才让客户感觉好用。
这时就不再是客户提需求了,而是我们主动地提需求、主动地改进功能,去解决客户的痛点,这样做的效果是,客户会感觉“不知道为什么,我就觉得你们的软件好用,用着很顺手”。这时,不但客户不会再改来改去,而且我们的软件做得也越来越专业,越来越有市场竞争力,这才是 DDD 的真谛。
这里有个问题,如果我们对业务理解不深刻就会影响到产品,那么能不能一开始就对业务理解得非常深刻呢?这几乎是不可能的。我们经常说,做事不能仅凭一腔热血,一定要符合自然规律。其实软件的设计开发过程也是这样。
在最开始你对业务理解比较粗略的时候,就从主要流程开始领域建模。
接着,不断往领域模型中加东西。随着功能一个一个地添加,领域模型也变得越来越丰富、越来越完善。每次添加新功能的时候,运用“两顶帽子”的方式先重构再加新功能,不断地完善每个设计。
这样,领域模型就像小树一样一点儿一点儿成长,最后完成所有的功能。
这样的设计过程叫“小步快跑”。采用小步快跑的设计方法,一开始不用思考那么多问题,从简单问题开始逐步深入,设计难度就降低了。同时,系统始终是处于变更中,使设计更加易于变更。
基于界限上下文的领域建模
回到前面章节的微服务设计部分,当在线订餐系统完成了事件风暴的分析以后,接着应当怎样设计呢?
通过划分限界上下文,已经将系统划分为了“用户注册”“用户下单”“饭店接单”“骑士派送”与“饭店管理”等几个限界上下文,这样的划分也是后端微服务的划分。
紧接着,就开始为每一个限界上下文进行领域建模。
首先,从“用户下单”上下文开始。通过业务领域分析,绘制出了如图 2