领域驱动设计(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.