聊聊DDD
领域驱动设计(Domain Driven Design, DDD),首先聊聊什么是领域
Domain knowledge explains the ‘why’ of what a business is doing and informs the decisions and testing for an application.
软件工程中领域知识就是我们的业务逻辑,他描述了业务具体做什么,并且为测试提供了验证依据。
按照不同的业务领域划分后,就拆分成了不同的微服务。
为什么需要DDD
DDD是为了处理领域复杂性,我们的代码往往不知不觉就随着业务的复杂性而失控,变得无法维护。
先看看项目现状,如果你的软件完全以数据为中心,所有操作都通过对数据库的CRUD完成,你的领域对象主要是gettter和setter方法,Service 层主要是 save ,update 方法,这样的代码会有什么问题吗?
那么你能从这样的代码里读懂业务逻辑,领域知识吗?换句话说这样的代码能体现我们的领域知识吗?
比如上面的代码这个方法你能知道的业务意图是什么吗?但这个方法确实无比强大,他可以更新商品任何信息,比如更新商品库存,商品名称,商品上下架状态等等,因为他的职责太多,导致最后代码无法维护。我们也很难知道到底有多少地方调用了这个方法。
如果我们把上面的方法拆解下这么样?
//修改商品基本信息
public boolean changeProductBaseInfo(String productName, String brand);
//商品下架 这里会修改商品上下架状态
public boolean offline(Long productId);
//商品销售 这里会有商品库存计算
public boolean sell(Long productId);
我们的方法名清晰的描述了意图,同时领域知识在代码里得到了体现,调用方也不需要关心里面的实现,比如商品销售后是否需要给用户送积分。
代码分层结构,Dao 层就是负责数据的持久化主要是CRUD,而service 层就是是对业务领域的实现,不能只是对Dao的简单调用。
同时对业务的操作也可以分为CQE(Command, Query, Event)
-
Command 是指令 是对业务状态有影响和改变的操作。
-
Query 主要是查看不会改变任务状态。
-
Event 是业务操作后产生的事件(比如用户订单支付成功, 用户取消订单)
Command主要体现我们的领域知识,Event 也是事件驱动,Query 可以独立查询的数据来源可以是数据库也可以是缓存,或者生成的报表。
总结:其实DDD的目的是为了让我们能应对复杂的业务,并且让业务领域知识能体现在代码里,化繁为简。当然我只是浅显的谈了些自己的看法,让大家认识到DDD的必要性,我们在实际应用中,也可以由浅入深逐步认识理解。希望大家happy coding.