领域驱动设计DDD实际项目落地最佳实践

领域驱动设计（Domain Driven Design，简称DD）设计思想和方法论早在2005年时候就被提出来，但是一直没有被重视和推荐使用，直到2015年之后微服务流行之后，再次被人重视和推荐使用。
下面我来介绍一下DDD设计思想和方法论，同时结合我们在实际项目中应用总结和思考。
目录
1、为什么要用DDD
2、DDD架构设计
3、领域建模方法
4、代码实践
5、问题总结
 
1、为什么要用DDD

面向过程
      很多时候，我们都是操着面向对象的语言干着面向过程的勾当。大部分的系统都是从单一业务开始的。但是随着支持的业务越来越多，代码里面开始出现大量的if-else逻辑，这个时候代码开始有坏味道，没闻到的同学就这么继续往上堆，闻到的同学会重构一下，但因为系统没有统一的可扩展架构，重构的技法也各不相同，这种代码的不一致性也是一种理解上的复杂度。
分层不合理
      分层太多和没有分层都会导致系统复杂度的上升。
随心所欲
      随心所欲是因为缺少规范和约束。
面向对象
     深入的理解面向对象设计原则、模式、方法论有很多，同时要具备非常好的业务理解力和抽象能力。
     SOLID是单一职责原则(SRP)，开闭原则(OCP)，里氏替换原则(LSP)，接口隔离原则(ISP)和依赖倒置原则(DIP)的缩写，原则是要比模式更基础更重要的指导准则，深入理解面向对象设计原则极大的提升我们的面向对象设计的能力和代码质量。
分层设计
      分层最大的好处就是分离关注点，让每一层只解决该层关注的问题，从而将复杂的问题简化，起到分而治之的作用。
领域建模
      领域模型可以准确地反映业务语言，使业务语义显性化，而传统的J2EE或Spring+Hibernate/Mybatis等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被称为成贫血模式。
规范设计
        各归其位、命名约定、通用业务状态码约定等。
DDD概念定义
领域驱动设计：一种软件开发方法，是一种软件核心复杂性应对之道，它可以帮助我们设计高质量的软件模型。
DDD目的：

• DDD是为了解决复杂业务逻辑的问题
  
• DDD的核心问题不是技术问题，而是关于讨论、聆听、理解、发现业务价值的问题
  
• DDD是技术人员拥有产品思维的一个体现
  
• DDD的学习曲线很陡主要是因为它是一种方法论，每个人对它的理解存在差异
  

 
领域模型与事务脚本对比

 
富血模型：就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。 service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity。
贫血模型：就是一个对象里只有属性，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，大量传统的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。
举个例子，银行转账实现类

各位看官看到上面的代码是不是有一种似曾相似的感觉？咋一看也没有啥问题，能正常运行，能快速交付业务。如果仅是为了应付需求任务交差，当然没有什么啥问题了。
从设计角度来看确实存在一些问题，代码糊在一起，没有分层设计，伪面向对象的方法。
我们码农总得要有自己一点的追求，为伟大代码事业创造一点艺术贡献！

• 如果业务需求快速变化怎么办，需求越来越复杂怎么办？
  
• 如果团队里面有多人协作，代码需要经过多人反复修改接手传承，你敢保证后面接手的人不会骂你吗？
  
• 难道设计上有没有可以改进的空间？
  

答案是正面的！
客观来说上面的这段代码不算复杂，也算写得中规中举。下面我来让贴一段曾经在我们实际生产系统跑了将近一年的神代码，你才知道什么叫复杂和神奇！16层if..else+for循环！就问你怕了没有？

<strong>》》》请点开看下面神码片段
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！