axonframework mysql_领域驱动+CQRS+AXON实践

一、概念理解

1、领域驱动设计(DDD)

传统方式的不足

过度耦合

一般业务初期，系统的功能大都非常简单，普通的CRUD就能满足，此时系统是清晰的。然而随着迭代的不断演化，业务逻辑变得越来越复杂，系统也越来越冗杂。模块彼此关联，谁都很难说清模块的具体功能意图是啥。修改一个功能时，往往光回溯该功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。

用DDD则可以很好地解决领域模型到设计模型的同步、演化，最后再将反映了领域的设计模型转为实际的代码。

注：模型是我们解决实际问题所抽象出来的概念模型，领域模型则表达与业务相关的事实；设计模型则描述了所要构建的系统。

贫血症和失忆症

贫血领域对象(Anemic Domain Object)是指仅用作数据载体，而没有行为和动作的领域对象。

当前大多开发模式，都是以数据为中心，以数据库ER设计作驱动，对象只是数据的载体，没有行为。即便对架构进行了分层，但是分层架构在这种开发模式下，也只是对数据的移动、处理和实现的过程。

更好的开发方式是采用领域模型，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

值对象

当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象(Value Object)。

例：比如性别信息，我们只需要知道{"sex":"男"}这样的值信息就能够满足要求了，这避免了我们对标识追踪带来的系统复杂性。

它具有不变性、相等性和可替换性。在实践中，需要保证值对象创建后就不能被修改，即不允许外部再修改其属性。

聚合根

Aggregate(聚合)是一组相关对象的集合，作为一个整体被外界访问，聚合由根实体，值对象和实体组成，聚合根(Aggregate Root)是这个聚合的根节点。

如何创建好的聚合？

边界内的内容具有一致性：在一个事务中只修改一个聚合实例。如果你发现边界内很难接受强一致，不管是出于性能或产品需求的考虑，应该考虑剥离出独立的聚合，采用最终一致的方式。

设计小聚合：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。

通过唯一标识来引用其他聚合或实体：当存在对象之间的关联时，建议引用其唯一标识而非引用其整体对象。如果是外部上下文中的实体，引用其唯一标识或将需要的属性构造值对象。如果聚合创建复杂，推荐使用工厂方法来屏蔽内部复杂的创建逻辑。

聚合内部多个组成对象的关系可以用来指导数据库创建，但不可避免存在一定的抗阻。如聚合中存在List，那么在数据库中建立1:N的关联需要将值对象单独建表，此时是有id的，建议不要将该id暴露到资源库外部，对外隐蔽。

领域服务

一些重要的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。

领域事件

领域事件是对领域内发生的活动进行的建模。

觉得美团技术团队写的《领域驱动设计在互联网业务开发中的实践》这篇文章挺好的，建议看看！

2、CQRS

CQRS理解

CQRS使用分离的接口将数据查询操作(Queries)和数据修改操作(Commands)分离开来，这也意味着在查询和更新过程中使用的数据模型也是不一样的。这样读和写逻辑就隔离开来了。

CQRS Model1

使用CQRS分离了读写职责之后，可以对数据进行读写分离操作来改进性能，可扩展性和安全。如下图：

CQRS Model2

主数据库处理CUD，从库处理R，从库的的结构可以和主库的结构完全一样，也可以不一样，从库主要用来进行只读的查询操作。在数量上从库的个数也可以根据查询的规模进行扩展，在业务逻辑上，也可以根据专题从主库中划分出不同的从库。从库也可以实现成ReportingDatabase，根据查询的业务需求，从主库中抽取一些必要的数据生成一系列查询报表来存储。

CQRS模式的优点如下：

1)分工明确，可以负责不同的部分

2)将业务上的命令和查询的职责分离能够提高系统的性能、可扩展性和安全性。并且在系统的演化中能够保持高度的灵活性，能够防止出现CRUD模式中，对查询或者修改中的某一方进行改动，导致另一方出现问题的情况。

3)可以从数据驱动(Data-Driven) 转到任务驱动(Task-Driven)以及事件驱动(Event-Driven).

但是在以下场景中，可能不适宜使用CQRS：

1)领域模型或者业务逻辑比较简单，这种情况下使用CQRS会把系统搞复杂。

2)对于简单的，CRUD模式的用户界面以及与之相关的数据访问操作已经足够的话，没必要使用CQRS，这些都是一个简单的对数据进行增删改查。

3