DDD架构
1.DDD架构的概念：
领域驱动设计（Domain-Driven Design, DDD）是一种软件设计方法，旨在将软件系统的设计和开发焦点集中在领域模型上，以解决复杂业务问题
2.DDD架构解决了什么问题:
在以前的mvc架构种，三层结构，简单明了。但是当项目越来越大，维护的时间久了的话，就会出现问题，各种PO，VO，DTO对象越来越多，并且会出现多个接口调用同一个VO对象
会导致实体类越来膨胀，时间久了实体类的定义越来越模糊。就变成了一屎山代码。
而DDD是让各个模块尽可能的都在自己的领域包中。那样会尽可能的减少PO VO的调用，相当于在MVC的基础，将实体类的贫血模型，改成了充血模型。
3.DDD架构各个模块
xfg-frame-api 接口定义
其实该module更多做的是为xfg-frame-trigger提供定义好的RPC接口，但是不仅仅只有这些，还有像HTTP接口，MQ接口，甚至TASK接口都可以在xfg-frame-api中定义好，
因为xfg-frame-trigger引用了xfg-frame-api，所以会直接impl即可
xfg-frame-app 应用封装
该module在我看来是应用启动和配置这一层的，比如你可以设置一些基本的配置，如AOP配置，线程池配置，数据库连接池配置等，通过整个项目的配置文件也在此处，包括 mybatis.xml 和 application.yaml等配置。这个类可以说是非常的重要，打包镜像就是在这一层，该module引入了xfg-frame-trigger 触发调用 和 xfg-frame-infrastructure 基础设施，也就是说将来在打包的时候，它可以被理解为专门为了启动服务而存在的
xfg-frame-domain 领域封装
领域模型服务，是一个非常重要的模块，无论怎么做DDD的分层架构，domain肯定是要存在的，那么在这一层中就要一个个的细分领域模型，也就是包含每个领域模型都要有的三大要素：“模型 仓库 服务”。
xfg-frame-infrastructure 基础设施|
这个层是依赖于domain领域层的，因为在domain层定义了仓库接口 需要在基础层实现，这是一个依赖倒置的一种设计思路。
前面说到了，在基础层实现了domain领域的接口，实现了其对应的接口的功能，而 xfg-frame-trigger中也引用了domain，那么通过多态，实际上，那么trigger中引入的domain里的仓库方法实际上由infrastructure 实现了
xfg-frame-trigger 触发调用
该层相对好理解，主要用于提供接口实现，消息接收，任务执行等，相当于触发器层，主要引入了 domain api 和 types
xfg-frame-types 类型定义
主要是作为通用类型定义层，在我们的系统开发中，会有很多类型的定义，包括基本的Response，Contants和枚举。它们会被其他层引用。
4.领域分层
这个地方是我认为DDD的核心部分了，也就是domain部分，前面其实还是较少介绍的，只说了其包含三个部分“模型 仓库 服务” 但是实际上包含着更多的内容，
如下图所示:
值对象：表示没有唯一标识的业务实体，例如商品的名称、描述、价格等。
实体对象：表示具有唯一标识的业务实体，例如订单、商品、用户等；
聚合对象：是一组相关的实体对象的根，用于保证实体对象之间的一致性和完整性；
4.1依赖倒置原则
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合
理解：高层模块不应该直接调用底层模块的具体实现，应该调用底层模块的抽象，这样当底层模块进行修改的时候不会影响高层模块。
4.2开闭原则
开闭原则（Open Closed Principle, OCP）是面向对象设计的基本原则之一，它要求软件实体（如模块、类、方法等）应当对扩展开放，对修改关闭。这意味着当软件的需求发生变化时，我们不需要修改原有的代码，而是通过扩展的方式来满足新的需求。
对扩展开放：允许在不修改现有代码的情况下增加新的功能或行为。
对修改关闭：限制对现有代码的修改，以减少代码的耦合性和提高系统的可维护性。
实现开闭原则的方法包括：
抽象约束，封装变化：通过接口或抽象类定义一个相对稳定的抽象层，而将可变的部分封装在具体实现类中。这样，当软件需要变化时，只需要添加新的实现类来扩展功能，而不需要修改原有的代码。
依赖抽象而非具体实现：通过依赖抽象类或接口而不是具体实现类来编程，可以提高代码的可复用性和可维护性。
使用设计模式：如策略模式、模板方法模式等，这些模式可以帮助我们更好地遵循开闭原则，实现代码的灵活性和可扩展性。
5.MVC分层架构
分层架构是典型的架构例子，该架构将元素按照“层”的方式组织，每个层有定义明确的职责，同时限制了层与层之间的依赖关系。即：每一层只能依赖于紧邻的下层或下面的任何层。以常见的三层架构为例（三层架构是应用于逻辑视图的分层架构），三层架构将应用程序的类组织展示如图2.1所示：
在实际开发过程中，三层架构随着业务的逐渐庞大会出现很明显的弊端，比如，在表示层中有逻辑层的代码，导致在实际的三层架构模型中，下层会依赖上层，违背了三层分层机构只能上层依赖下层的原则，导致分层边界越来越模糊。