网站营运,企业年检网上申报流程,升级wordpress ftp,大良网站建设服务1.DDD架构的概念#xff1a; 领域驱动设计#xff08;Domain-Driven Design, DDD#xff09;是一种软件设计方法#xff0c;旨在将软件系统的设计和开发焦点集中在领域模型上#xff0c;以解决复杂业务问题 2.DDD架构解决了什么问题: 在以前的mvc架构种#xff0c;三层结…1.DDD架构的概念 领域驱动设计Domain-Driven Design, DDD是一种软件设计方法旨在将软件系统的设计和开发焦点集中在领域模型上以解决复杂业务问题 2.DDD架构解决了什么问题: 在以前的mvc架构种三层结构简单明了。但是当项目越来越大维护的时间久了的话就会出现问题各种POVODTO对象越来越多并且会出现多个接口调用同一个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 类型定义 主要是作为通用类型定义层在我们的系统开发中会有很多类型的定义包括基本的ResponseContants和枚举。它们会被其他层引用。
4.领域分层 这个地方是我认为DDD的核心部分了也就是domain部分前面其实还是较少介绍的只说了其包含三个部分“模型 仓库 服务” 但是实际上包含着更多的内容 如下图所示:
值对象表示没有唯一标识的业务实体例如商品的名称、描述、价格等。 实体对象表示具有唯一标识的业务实体例如订单、商品、用户等 聚合对象是一组相关的实体对象的根用于保证实体对象之间的一致性和完整性
4.1依赖倒置原则 依赖倒置原则的原始定义为高层模块不应该依赖低层模块两者都应该依赖其抽象抽象不应该依赖细节细节应该依赖抽象。其核心思想是要面向接口编程不要面向实现编程。依赖倒置原则是实现开闭原则的重要途径之一它降低了客户与实现模块之间的耦合
理解高层模块不应该直接调用底层模块的具体实现应该调用底层模块的抽象这样当底层模块进行修改的时候不会影响高层模块。
4.2开闭原则 开闭原则Open Closed Principle, OCP是面向对象设计的基本原则之一它要求软件实体如模块、类、方法等应当对扩展开放对修改关闭。这意味着当软件的需求发生变化时我们不需要修改原有的代码而是通过扩展的方式来满足新的需求。 对扩展开放允许在不修改现有代码的情况下增加新的功能或行为。 对修改关闭限制对现有代码的修改以减少代码的耦合性和提高系统的可维护性。
实现开闭原则的方法包括 抽象约束封装变化通过接口或抽象类定义一个相对稳定的抽象层而将可变的部分封装在具体实现类中。这样当软件需要变化时只需要添加新的实现类来扩展功能而不需要修改原有的代码。 依赖抽象而非具体实现通过依赖抽象类或接口而不是具体实现类来编程可以提高代码的可复用性和可维护性。 使用设计模式如策略模式、模板方法模式等这些模式可以帮助我们更好地遵循开闭原则实现代码的灵活性和可扩展性。
5.MVC分层架构 分层架构是典型的架构例子该架构将元素按照“层”的方式组织每个层有定义明确的职责同时限制了层与层之间的依赖关系。即每一层只能依赖于紧邻的下层或下面的任何层。以常见的三层架构为例三层架构是应用于逻辑视图的分层架构三层架构将应用程序的类组织展示如图2.1所示
在实际开发过程中三层架构随着业务的逐渐庞大会出现很明显的弊端比如在表示层中有逻辑层的代码导致在实际的三层架构模型中下层会依赖上层违背了三层分层机构只能上层依赖下层的原则导致分层边界越来越模糊。
