DDD
DDD是Eric Evans于2003年出版的书名，同时也是这个架构设计方法名的起源。Eric Evans “领域驱动设计之父”，世界杰出软件建模专家。他创建了Domain Language公司，致力于帮助公司机构创建与业务紧密相关的软件。他在世界各地宣讲领域驱动设计（Domain-Driven Design，DDD）的思想，开设课程，参加会议，接受专访，拥有大批的追随者。从20世纪80年代开始，他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发，涉及各种复杂的业务和技术领域。同时，他还培训和指导过许多开发团队开展极限编程实践。
DDD的好处是啥
Domain Driven Design
DDD不是架构，而是一种方法论（Methodology）微服务架构从一出来就没有很好的理论支撑如何合理的划分服务边界，人们常常为服务要划分多大而争吵不休
四色原型建模
某个人（Party）的角色（PartyRole）在某个地点（Place）的角色（PlaceRole）用某个东西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）
分层架构
分层架构是将软件模块按照水平切分的方式分成多个层,最基本的是分层架构是三层，即表现层，领域层和数据持久层
DDD中 四层架构 表现层，应用层、领域层和基础层
四层中的应用层是对三层架构中领域层进行进一步拆分。但是无论怎么分层，业务逻辑永远在领域层。
三层架构：
表现层：负责向用户展示信息和接收用户的指令。需要负责处理展示逻辑，比如用户通过我们的系统进行信用卡还款，系统会返回三个状态未申请，处理中，处理完成。表面层需要根据这个状态给用户返回不同的页面，根据这三个不同的状态，向用户展示不同的中文说明。
领域层：负责表达业务逻辑，是整个系统的核心层。比如信用卡还款服务。
持久层：提供数据查询和存储服务，包括按照状态查询信用卡。
四层架构：
表现层：同三层架构表现层。
应用层：定义软件要完成的任务，不包含业务逻辑，而是协调，比如受理用户请求的任务。负责非
业务逻辑（批量删除、修改等）
领域层：同三层架构领域层。
基础层：为各层提供通用的技术能力。为领域层提供数据和文件存储
分层架构最重要的是每一层关注自己的职责，持久层只负责提供查询、更新和存储数据的服务，和业务逻辑无关的，所以持久层提供按照还款状态查询信用卡的服务，这样做的好处增加复用性，后续领域层提供展示已还款的信用卡服务时能复用持久层的查询服务。
分层架构的好处
分层架构的目的是通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。
单一职责：每一层只负责一个职责，职责边界清晰，如持久层只负责数据查询和存储，领域层只负责处理业务逻辑。
高内聚：分层是把相同的职责放在同一个层中，所有业务逻辑内聚在领域层。这样做有什么好处呢？试想一下假如业务逻辑分散在每一层，修改功能需要去各层修改，测试业务逻辑需要测试所有层的代码，这样增加了整个软件的复杂度和测试难度。
低耦合：依赖关系非常简单，上层只能依赖于下层，没有循环依赖。
可复用：某项能力可以复用给多个业务流程。比如持久层提供按照还款状态查询信用卡的服务，既可以给申请信用卡做判断使用，也可以给展示未还款信用卡使用。
易维护：面对变更容易修改。把所有对外接口都放在对外接口层，一旦外部依赖的接口被修改，只需要改这个层的代码即可。
以上这些既是分层的好处也是分层的原则，大家在分层时需要遵循以上原则，不恰当的分层会违背了分层架构的初衷。
分层架构的缺点
分层架构也有几个缺点：
开发成本高：因为多层分别承担各自的职责，增加功能需要在多个层增加代码，这样难免会增加开发成本。但是合理的能力抽象可以提高了复用性，又能降低开发成本。
性能略低：业务流需要经过多层代码的处理，性能会有所消耗。
可扩展性低：因为上下层之间存在耦合度，所有有些功能变化可能涉及到多层的修改
领域模型 domain model
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、业务对象模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。优点是系统的层次结构清楚，各层之间单向依赖，Client->（Business Facade）->Business Logic->Data Access Object。可见，领域对象几乎只作传输介质之用，不会影响到层次的划分。领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象
贫血模型
指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在Business Logic层。在使用Spring的时候，通常暗示着你使用了贫血模型，我们把Domain类用来单纯地存储数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层）可以被设计成singleton的bean。假使我们这里逆天而行，硬要在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦，比如：bean之间的引用，可能引起大范围的bean之间的嵌套构造器的调用
充血模型
大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（BusinessFacade）->Business Logic->Domain Object->Data Access Object
优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在BusinessLogic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在DomainLogic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。使用RoR开发时， 每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。充血模型的层次和模块的划分是一门学问，对开发人员要求亦较高，可以考虑定义这样的一些规则：
（1）事务控制不要放在领域模型的对象中实现，可以放在facade中完成。
（2）领域模型对象中只保留该模型驱动的一般方法，对于业务特征明显的特异场景方法调用放在facade中完成
传统的数据驱动开发模式
View、Service、dao这种三层分层模式，开发者会很自然的写出过程式代码，这种开发方式中的对象只是数据载体，而没有行为，是一种贫血对象模型。以数据为中心，以数据库ER图为设计驱动，分层架构在这种开发模式下可以认为是数据处理和实现的过程。Bounded Context定义了每个模型的应用范围
什么是 CQRS？
CQRS — Command Query Responsibility Segregation，故名思义是将 command 与 query 分离的一种模式。query 很好理解，就是我们之前提到的「查询」，那么 command 即命令又是什么呢？我们仔细看CRUD, 其实可以更简单的分为读(R)和写(CUD), 我们想想大部分情况都是，一个方法要么是执行一个Command完成一个动作，要么就是查询返回数据。 比如我们回答问题的人不应该去修改问题。当我们读写分离后，我们对应的代码也会分离
统一语言(Ubiquitous Language)
业务人员和我们使用一样的语言，我们的程序比如让业务尽量集中在领域里
聚合根
