DDD的精髓

定义一个拥有balance属性(同时有getter&setter)的Account对象，然后在一个TransferTransactionFunc
事务函数中分别查出对应的account实体， 再直接调用实体的getter&setter方法获取和
更新balance，计算过程也呈现这个函数中，没有过多封装；
*特点*：是初期实现简单、直观，但随着业务需求迭代，这样的代码就不好优化，也不可能把新逻辑都堆
在此方法中，特别是在后期来重新优化改造，成本巨大，易出bug

在方案一的基础上进行改进，Account对象增加incr/decr即增减余额方法，然后事务函数就只需要调用account
实体的incr/decr方法完成业务逻辑了
*特点*：在初期就将职责划分的比较清晰，增减余额应当归于Account自身的逻辑，不应暴露给外部操作；相比
方案一来说，强化了域（Domain）的概念，将域的职责进行严格划分（域是一个泛概念，可以指代类，服务）；
这样，在后期优化时，改动的是Account的方法而不是事务函数，同时提醒后面的开发人员延续这种封装风格

主要思想：通过在业务和代码中的技术之间采用共同术语达到让开发的程序
和业务相匹配的效果

业务语言中的术语由业务侧和技术侧同事共同协商定义，目的是创建大家都认可，无歧义的统一术语

代码、类、方法、属性和模块的命名必须和统一术语相匹配，必要时对代码进行重构

最终收益：极大提升业务部门和技术部门的沟通&工作效率

DDD的核心是领域模型，而领域模型的精髓则在于面向对象、对事物的抽象能力；
一个DDD架构师必然是一个面向对象分析大师

DDD鼓励我们接到需求后的第一步是考虑领域模型，而不是切割为数据和行为；

强调的是业务抽象和面向对象编程，而不是过程式编程，重点不同，导致代码实现架构完全不同

前面2点都是为了提高代码可读性和可维护性。同时，代码也尽可能体现出了领域实体之间的关系原貌，
让代码更容易理解和维护，显然就降低了系统复杂度

代码复杂度是由业务复杂度和技术复杂度组成的，DDD让我们可以分离业务逻辑和技术细节，
比如业务逻辑是给某账户加/减钱，那技术细节就是在对应数据表中更改数据

DB、Framework、Component（不论前后端）都是技术细节，不应该影响业务逻辑的实现

代码世界中定义的能够一对一对应现实世界中事物的实体（对象），以及它们的职责、行为和之间关系

- 比如租房业务中有租客和房东（还有中介、房子）几个角色和事物，那么建模后代码中也会定义对应的对象

是DDD中的一个概念，是一中更大范围的封装。它把一组具有相同生命周期、在业务上
不可分割的实体和值对象放在一起，只有根实体可以对外暴露引用（也是内聚的体现）

- 比如房东是房子（实体）、房东个人信息（值对象）以及房东钱包（实体）的聚合根

有些领域中的动作是动词，看上去并不属于任何对象。这时不能忽略它们或
简单将其归类到某个实体或值对象中；推荐的实践方式是将它声明为一个服务，即Service

- 比如银行转账案例中，转账行为发生在两个账号之间，将其归属于某个账号并不合适，所以
直接命名为MoneyTransferDomainService就比较合适

识别这个主要看其是否满足3个特征

定义：是一个特点领域由一个用户动作触发的事件，且这个事件是系统其他部分和关联系统感兴趣的
（可理解为分布式系统中生产于用户，消息组件暂存的事件）

注意几点

领域实体的意义是有上下文边界的
- 比如同样是apple，手机店和水果店的apple就完全不同

在同一个上下文中，要保证模型在逻辑上统一

扩展——防腐层（Anti-corruption layer）