营销网站建设品牌企业,兰溪优秀高端网站设计地址,成立公司怎么做网站,怎么清除网站本部分对常见架构进行简单的说明。
一、三层架构之经典 MVC
经典的 MVC 架构#xff08;Model-View-Controller#xff09;架构是软件系统架构设计中的经典#xff0c;它将应用程序分为三个主要部分#xff1a;
模型#xff08;Model#xff09;视图#xff08;ViewModel-View-Controller架构是软件系统架构设计中的经典它将应用程序分为三个主要部分
模型Model视图View控制器Controller
这样的三层架构有助于实现业务逻辑的分离提高代码的可维护性和可扩展性。
二、 CQRS命令查询职责分离
命令查询职责分离模式Command Query Responsibility SegregationCQRS是一种软件架构模式它通过从业务上分离修改Command增、删、改会对系统状态进行修改和查询Query查不会对系统状态进行修改的行为使逻辑清晰提高系统的可维护性和灵活性。 1 、优点
业务逻辑清晰将修改和查询操作分开使业务逻辑更加清晰。命令负责修改状态而查询负责获取信息降低系统复杂性可维护性增强通过将写模型和读模型分离可以独立演化和优化两者。提高了系统的可维护性开发人员可以更容易地理解和修改两个模型扩展性支持根据系统需求独立扩展命令和查询部分这种灵活性使得系统更容易适应不断变化的需求更好的性能优化通过专门优化读模型可以更好地满足查询性能的需求有助于提高系统的整体性能
2 、不足
结构复杂引入两个独立的模型读写使得系统结构复杂度高维护和理解这两个模型之间的关系可能需要更多的工作冗余代码由于存在独立的读写模型可能导致代码冗余特别是对于一些共享的业务逻辑这需要谨慎的设计和维护以避免冗余性能问题涉及多次数据库操作可能导致性能问题特别是在需要频繁进行读写操作的情况下需要根据具体情况进行性能优化工作流不直观将任务分解为多个步骤可能导致工作流难以理解尤其是对于新加入的开发人员文档和培训对于确保团队对工作流的理解至关重要缺乏标准化并没有广泛的标准团队在实践中需要根据自身需求进行调整可能缺乏一致性和规范性
3 、总结
CQRS 是一个特定场景下有益的架构模式但在引入时需要仔细权衡其优缺点。在对系统的可维护性、可扩展性和性能有较高要求的情况下CQRS 可能是一个有价值的选择。然而对于简单的应用程序引入 CQRS 可能会增加不必要的复杂性。在实践中团队应该根据具体情况慎重考虑是否采用 CQRS 。
三、六边形架构
六边形架构Hexagonal Architecture也称为端口适配器模式是 Alistair Cockburn 在 2005 年首次提出的一种软件架构模式。其主要目标是将应用程序的核心逻辑与特定的输入/输出技术解耦使其能够更灵活的应对变化和演化。
1 、三个原则
明确分层层次Explicitly separate ApplicationDomainand Infrastructure
在六边形架构中明确分离应用程序Application、领域Domain和基础设施Infrastructure是关键的设计原则这种分离使开发者将关注点分离开每一层都可以独立变化而不影响其他层提高了系统的可维护性、可测试性和可扩展性。
应用程序层Application Layer 责任包含应用程序的业务逻辑负责协调领域层和基础设施层的交互不包含具体的业务规则而是将请求委托给领域层进行处理实现通常由应用服务组成提供用例的实现负责接收外部请求、处理输入数据、协调领域层的操作并调用适当的基础设施服务
领域层Domain Layer 责任包含系统的核心业务逻辑和领域模型这是系统的灵魂包含了问题域的概念、规则和约束实现由实体Entities、值对象Value Objects、聚合Aggregates、领域服务Domain Services等构成协调工作实现业务规则确保系统的行为符合领域的要求
基础设施层Infrastructure Layer 责任负责处理与外部系统的通信、数据库访问、日志记录等与具体技术相关的事务包含所有与技术实现有关的组件实现 包括数据库访问层、外部服务通信层、日志记录、配置等这些组件对系统的业务逻辑是透明的通过接口与应用程序层和领域层进行交互 依赖关系指向领域层Dependencies are going from Application and infrastructure to the Domain
确保领域层保持独立性不依赖于具体的应用程序逻辑或基础设施技术提高系统的可测试性、可维护性和可扩展性。
技术上就是 Application 和 Infrastructure 都不能直接互相调用对方的功能或者操作只有经过 Domain 的接口才能沟通确保 Domain 部分具有完整的独立性不受 Application 和 Infrastructure 变更的影响从而保持稳定这样的代码结构易读、易管理、易维护。
依赖关系的方向 应用程序层向领域层的依赖应用程序层包含用例的实现负责协调系统的操作并调用领域层的服务基础设施层向领域层的依赖基础设施层包含与技术实现相关的组件领域层不应该直接依赖于这些具体的技术实现而是通过接口定义领域层所需的服务并由基础设施层来实现这些接口
实现方式 领域服务接口在领域层中定义接口描述领域服务的行为这些接口是应用程序层和基础设施层依赖的抽象 ➡️ 如果领域层需要使用某种外部服务可以在领域层定义一个接口然后在基础设施层中实现这个接口依赖反转通过依赖反转原则应用程序层和基础设施层不直接依赖于领域层的具体实现而是依赖于领域层定义的接口和抽象这会让领域层能独立于其他层进行演化不受具体实现细节的影响测试驱动开发将依赖关系的方向设计成从应用程序和基础设施指向领域有助于采用 TDD通过在应用程序层和基础设施层编写测试用例并通过模拟或替代领域层的具体实现可以更容易进行单元测试确保领域层的正确性 使用端口和适配器隔离边界We isolate the boundaries by using Ports and Adapters
六边形架构使用端口和适配器模式来隔离系统的边界以提高系统的可测试性、可维护性和灵活性目标是将业务逻辑与外部环境解耦让系统的各个部分更容易替换、测试和理解
基本概念 端口定义系统与外界通信的接口表示系统的一种能力或服务通常通过接口来表示定义系统对外提供的服务不关心具体的实现只关注服务的契约适配器连接系统内部和外部的组件负责将系统内的数据结构或接口转换成外部系统期望的形式是外部环境和系统内部通信的桥梁确保系统的核心业务逻辑不受业务环境的影响
具体应用 内部端口和适配器将应用程序划分为核心业务逻辑Application和外部环境Infrastructure两部分内部端口表示系统对外部环境提供的服务而内部适配器则负责将内部数据结构适应外部环境的需求外部端口和适配器外部端口表示系统对外部环境的依赖而外部适配器则将外部环境的服务适配成系统内部期望的形式使系统的核心业务逻辑不直接依赖于具体的外部实现而是通过端口和适配器与外部环境进行通信 2 、特点
对称性系统的设计围绕着一个中心的应用核心组件所有的交互都必须通过这个中心隔离性应用程序的核心组件被一层薄的适配器包围使得它对外部环境的变化免疫可插拔性系统可以通过改变其适配器来更改接口并适应不同的上下文
3 、组成部分
应用核心整个架构的心脏包含了应用程序的业务逻辑和领域模型不依赖任何特定的外部元素只关注应用程序的核心功能端口是应用程序核心向外提供的接口定义了应用程序如何与外部世界进行通信适配器用于连接应用程序核心和外部世界的栋梁实现了端口的具体行为并将请求路由到正确的位置
4 、好处
灵活性当外部环境发生变化时只需要修改适配器即可而无需触及应用程序的核心测试友好可以轻松模拟和替换适配器从而更容易测试应用程序的核心部分低耦合应用程序的核心部分与外部环境完全解耦使其更易于维护和扩展
5 、不足
设计复杂度高需要花费更多时间进行需求分析和设计学习曲线比较陡峭需要具备一定的软件设计知识
6 、总结
六边形架构是一种有助于提高代码代码质量和维护性的设计方式但它也有一定的学习成本和实施难度。在实际应用中可以根据具体项目的规模和复杂程度以及团队的技术能力灵活运用此模式。 四、洋葱架构 洋葱架构Onion Architecture是由 2008 年Jeffrey Palermo 提出它在端口和适配器架构的基础上将领域放在应用中心将用户用例和基础设施放在外围这种设计思路类似于六边形架构都是通过适配器代码将应用核心从对基础设施的关注中解放出来以避免基础设施代码渗透到应用核心之中使得框架和中间件需要改变替换的时候更加轻松不会影响到核心领域。
1 、设计原则
依赖性洋葱架构中的圆圈代表不同的责任层进入越深越接近领域和业务规则外圈代表机制内圈代表核心领域逻辑外层依赖于内层而内层对外圈一无所知数据封装每个圈层封装内部实现细节向外层公开接口在内层定义抽象接口在外层提供具体实现确保专注于领域模型而不必过多地担心实现细节。运行时可以使用依赖注入框架将接口和实现连接起来关注点分离应用系统被分为多个层级每一个层级都有一组职责并解决不同的关注点耦合性低耦合性一个模块和另一个模块交互时不需要关注另一个模块的内部具体实现所有的内部层级不需要关注外部层级的具体实现
2 、架构分层
应用服务层负责协调请求步骤的服务不应该有任何业务逻辑应用服务与其他服务交互来满足客户请求领域服务层负责保持领域逻辑和业务规则所有的业务逻辑应该作为领域服务的一部分来实现。领域服务由应用服务协调服务于业务用例。不是简单的 CRUD 服务领域模型层封装属性和实体行为基础设施层在洋葱架构中的最外层负责与外部世界交互不解决任何领域的问题没有任何逻辑可观察性服务层负责监控应用可以用于数据收集指标、日志、痕迹、数据存储、可视化等
3 、优势
洋葱架构建立在一个领域模型上各层之间通过接口交互其设计思想是在领域实体和业务规则构成架构的核心部分时尽可能将外部依赖性保持在外
提供灵活、可持续和可移植的架构各层之间没有紧密耦合且有关注点的分离所有代码都依赖更深的层或者中心提高可维护性提高整体代码的可测试性单元测试可以在单独的层创建不会影响其他的模块框架/技术可以容易改变而不影响核心领域
4 、不足
设计复杂性多个端口和适配器需要额外的设计工作且增加了系统复杂度维护困难洋葱架构的系统非常复杂对应的维护难度也比较高
5 、总结
洋葱架构适用于大型、复杂的应用程序对于需要长期维护和演进的系统其设计理念有助于降低变更的风险提高系统的可靠性和可扩展性在具体应用时可以根据项目规模和团队技术水平做出适当的调整。
