我从DDD中学到了什么

• DDD， domain-driven-develop，领域驱动设计。最近看了一些文章和eric evans那本《领域驱动设计：软件复杂性之道》，谈谈我从DDD中学到了什么。

DDD中的几个概念

• valueObject: 无状态，纯pojo的一些类，一般是不可变的，不可变意味着安全和简单，所以能归为valueObject的尽量归为valueObject。
• entity：一般是有全局id的，有状态的类，entity不应该是只有数据没有行为的贫血模型，而应该是封装了数据和行为的模型。
• aggregate：多个相互关联的entity和valueObject组成一个aggregate，aggregate内部高聚合，aggregate之间松耦合。
• aggregate root：访问一个aggregate的入口，一个aggregate内的所有元素都应该只能通过aggregate root来访问。两个aggregate之间的联系也应该是仅通过aggregate root。

为什么要有这些概念

• valueObject没啥说的，pojo类，即使不提DDD的概念，也是少不了的，在DDD中提出valueObject的概念是为了强调valueObject是不可变的，简单的，安全的，所以能设计成valueObject的都设计成valueObject吧
• entity：entity很多时候是对应于我们业务上要建模的一个对象，DDD中主要强调entity不应该是贫血模型，否则，行为会分散到各种地方。
• aggregate ：aggregate保证了aggregate内部的事物性，保证了数据的完整性。
• aggregate root：访问一个aggregate的入口只能是aggregate root的规则大大降低了模型的复杂度，和保证数据完整性。想一想，我们有几十种对象，每个对象都可能和其他对象相关联，这种模型后来人怎么维护。同时，如果我们变更了其中的某个对象A的一条记录，引用A的B，C，D...是不是要跟着改，有一个忘记改了，就会造成数据不一致。

DDD中的层级依赖结构

• interface层：和外部交互的接口，dto， controller等，在这一层捕捉到所有到异常，不要将异常带到客户端
• application层：根据use case 去做流程的串联。
• domain层：entity aggregate，repository接口等都在这一层，这一层不依赖于其他层。
• infra层：一些不常变的基础设施，比如持久化，rpc的实现等。
• 为什么说domain driven呢，因为domain层在最底层，我们在设计实现时，应该从这一层开始。
• 引入repository模式，比如持久化通过repository实现，一个很好的原则是，repository的入参应该是aggregate root，这样一方面确保了aggregate数据的完整性。同时，由于我们无法直接从db或者第三方获取到aggregate内部的对象，也就阻止了我们面向db编程的方式。

总结

• 回想之前的一些代码里的问题：1.边界不清晰，各个对象直接关系错综复杂，可以使用aggregate来梳理2.面向db编程，很多时候数据更改直接掉持久化接口就改db了，很容易造成数据不一致，应该面向domain编程，不应该看到db的接口，看到的只是domain层的对象。3.贫血模型，代码中充斥着util，manager，代码复用性差。应该构建既有数据又有行为的模型。4.DO DTO，domain entity的耦合，很多时候，一个类既是DO，又是DTO，又是domain entity。这三着应该拆开，即使拆开之后，可能三者基本一样。不然db表中新增一个字段，都得client配合升级

标签：domain,中学,什么,db,entity,valueObject,aggregate,DDD
来源： https://www.cnblogs.com/noooone/p/14766377.html