1.支持多数据源
2.层次清晰,敏捷化开发
3.依赖注入

->实体        具备唯一ID,可以持久化到数据库,一般对应数据库里的表
->值对象      可以是实体的某个属性,也可以是临时的某个属性,用于描述领域模型里的某个对象
->领域事件    接收应用层委派业务逻辑的行为,通常指某个领域对外暴露的方法
->仓储        管理实体的的一组集合,一般通过某个ORM实现,通过仓储来操作实体
->聚合/聚合根 定义领域模型,将N个模型或值对象聚合成一个模型,它们是一个整体,聚合根是对外暴露的唯一对象,只能通过这个这个对象操作模型
->工厂        用来封装,构建领域模型的方式		

业务逻辑本身就是领域模型的生成逻辑,我们是根据业务逻辑来聚合领域模型的,
目前软件开发的流程跟DDD是有区别的,如果按照DDD进行,第一步就应该是统一语言,
将所有参与者的关注点都聚集在领域模型上,所有讨论话题都是围绕这个领域模型展开,
开发者再将这个领域模型,拆分成实体,值对象...进行存储,
以前我们都是根据需求进行拆分功能,但是需求是多变的,不可控的,他们之间的隔阂在于,
产品并不关注你怎么管理这堆数据,以及数据之间的关联关系,需求的变化往往会打乱这些关联关系,导致结构很乱.
DDD的另一个难以推广的原因,是对领域模型的理解上,一般公司是缺乏领域专家的,简单来说,
在做这个项目的时候,他自己都不晓得要做成个什么样子,这给程序设计带来了极大的麻烦,
举个例子,如果公司要做个人的模型,因为大家对人在熟悉不过了,这个模型非常好搭建,讨论也很顺利,
设计完成后,老板说自己想要一个飞人,然后专家又一起讨论一个可以安装到人上的飞行器模型......N个版本后,
老板说,希望这个人能够具备变身成奥特曼的能力,能像孙悟空那样七十二变,... 这个时候人模型已经聚合不上其它模型了,
需要从新构建一个神的模型,领域专家知道人跟神的边界在哪里,但是因为实际工作中缺乏这样的领域专家,
开发者自己定义模型,可能前期就定义了一个狗的模型,然后给整了个人模狗样的产品,滑稽