为什么要DDD

一、传统架构的劣势

• 0、面向数据库建模，更加关注数据、关注有哪些表哪些列，只要数据最终落库，中间逻辑可以采取任何形式。忽略了业务中非常重要的“行为\动作\业务逻辑” 的建模，导致中间层要么臃肿、要么流水账、要么逻辑分散，没有真正“面向对象”。最终导致系统被数据库“绑架”，业务走向复杂。
• 1、传统controller、service、dao三层架构的业务逻辑分散到多个地方、如一部分逻辑在sql中、一部分在service中、甚至有的直接在controller中，导致更换开发人员后代码不易维护
• 2、传统三层架构面向数据库编程，本质上是数据库的事务脚本，service里充斥着过程代码、胶水代码，多人维护过程中会不断修改、添加service中的逻辑，service会随着开发时间越来越臃肿，当然，为了避免臃肿也会有诸如策略模式等设计模式的引入，但不能改变胶水代码本质，比如service代码中即可能有redisTemplate又可能有mapper和kafkaTemplate等，最终导致service代码因为不同原因而改变，不符合单一职责原则
• 3、传统三层架构虽然在形式上分为三层，但是并没有在编译器级别对代码有约束，实现分层全靠程序员自己的意识，这种代码并没有充分利用到编程语言提供的封装性质，最后轻则service之间形成网状结构调用，重则service层调用controller层反向调用，导致代码逻辑混乱
• 4、wiki是知识的坟墓在传统三层架构中体现的淋漓尽致，文档不易维护，并且随着时间推移旧知识将逐渐被代码的爆发式发展抛弃，最后新人过来不知所云，找不到一个关于业务的完整知识，出现面对老代码不敢改，怕改后出现问题，怕改不全等问题

注：上述描述的问题可以通过架构手段和其他技术手段来规避或者避免，但可能会失去这种分层架构带来的简单性。

二、DDD的优势

• 0、面向领域建模，不被某项存储技术绑架
• 1、领域逻辑高内聚，真正的面向对象编程。
• 2、不需要wiki维护，业务代码自解释，后来人员好接手
• 3、技术细节变更如数据库、缓存、定时器等的变更对业务逻辑影响比较小，非常适合插件式架构。本条实际上是ddd和整洁架构综合带来的优势。
• 4、程序员的代码更加可读、更加清晰、更加贴合业务，离客户更近。代码即业务\设计、业务\设计即代码，直接映射。

三、DDD的收益

• 1、思想带来的收益，代码直接映射现实世界概念
• 2、整洁架构带来的收益，底层技术如框架、数据库、缓存、kafka等变更不会对核心业务逻辑造成影响
• 3、整洁架构带来的收益，代码可维护性更强，对后续扩展、移植等支持更好，分层更加科学
• 4、思想带来的收益，程序员通过DDD对业务理解更加透彻，写的代码可以更好的传达客户的业务诉求
• 5、思想带来的收益，解耦业务、为服务化提供指导思想。架构更加清晰

四、DDD劣势

• 1、学习曲线陡峭，落地无框架支持
• 2、前期相比传统架构代码量更多，主要集中在DTO等数据对象
• 3、开发人员前期投入要更多，如事件风暴、聚合划分、事务处理等，工作量更多

五、建议

• 1、可以确定的小且简单的、没有后续增长的项目建议使用crud，简单快速
• 2、如果有过DDD实践经验的可以在任何时期进行DDD
• 3、对于业务逻辑复杂，或者可预见的会从简单变复杂的项目，建议DDD
• 4、不要为了ddd而ddd，不要空谈理论没有实践，不要在一个新项目中引入太多需要学习的概念或者技术。