前言整洁架构又被称为 “洋葱架构”其命名源于它独特的分层设计。从相关示意图中可以清晰看到整洁架构的各个层次就如同一片片洋葱片层层包裹形象地展现了分层的设计理念。在整洁架构里由同心圆来代表应用软件的不同组成部分。从最核心的内层开始依次向外分别是领域模型、领域服务、应用服务而最外层则是那些容易发生变化的内容例如用户界面和基础设施。领域模型处于最核心位置它承载着业务的核心概念和规则领域服务基于领域模型提供相关的业务逻辑服务应用服务则负责协调不同领域服务以满足具体的应用场景需求最外层的用户界面和基础设施虽然容易变动但通过这种分层架构它们的变化不会轻易影响到核心的业务逻辑。整洁架构最为关键的原则是依赖原则。该原则明确了各层之间的依赖关系越靠近内层依赖程度越低代码的级别越高代表着系统的核心能力。而且外圆代码的依赖只能指向内圆内圆的代码无需知晓外圆的任何情况。这种依赖规则保障了核心业务逻辑的稳定性和独立性使得系统在面对外部变化时能够保持核心功能的正常运行极大地提高了软件系统的可维护性和可扩展性。洋葱架构即整洁架构以独特的分层设计为核心。从架构图可见其各层如洋葱般层层嵌套这种设计理念直观且富有层次。在洋葱架构中各层职能划分明确。最核心的领域模型承载着领域内的核心业务逻辑封装企业级业务规则。领域模型的主体是实体实体既可以是带有方法的对象也能是数据结构与方法的集合它是业务规则的具体载体。领域服务则负责处理涉及多个实体的复杂业务逻辑。当业务逻辑涉及多个实体的交互与协作时领域服务就发挥作用将这些复杂逻辑进行整合与实现。应用服务主要围绕用户操作展开进行服务的组合与编排。它涵盖了应用特有的业务流程规则把系统所有用例进行封装与实现是连接用户操作与底层业务逻辑的关键桥梁。最外层的主要职能是提供适配能力可分为主动适配和被动适配。主动适配面向外部用户、网页、批处理以及自动化测试等实现它们对内层业务逻辑的访问适配被动适配则是为核心业务逻辑访问基础资源如数据库、缓存、文件系统和消息中间件等提供适配。值得一提的是红圈内的领域模型、领域服务和应用服务共同构成了软件的核心业务能力。这三部分紧密协作领域模型提供基础规则领域服务处理复杂逻辑应用服务负责面向用户的业务流程编排它们是软件得以正常运转、发挥核心价值的关键所在。六边形架构六边形架构也被称作 “端口适配器架构”。在追溯微服务架构的发展历程时六边形架构是绕不开的重要概念。它的核心理念聚焦于应用与外部交互的方式即应用通过端口与外部进行交互 这一理念也正是微服务架构中 API 网关被广泛应用的关键原因。从架构图来看在六边形架构里红圈内的核心业务逻辑包含应用程序和领域模型与外部资源如 APP、Web 应用以及数据库资源等处于完全隔离的状态。它们之间仅通过适配器进行交互。这种设计有效解决了业务逻辑与用户界面代码相互交错的问题极为出色地实现了前后端分离使得前端专注于用户交互展示后端聚焦于业务逻辑处理提升了系统的可维护性和可扩展性。值得注意的是六边形架构各层的依赖关系和整洁架构一致均为由外向内依赖。外层的各类资源依赖于内层的核心业务逻辑而内层核心业务逻辑无需了解外层资源的具体情况保障了核心业务的稳定性和独立性让系统在面对外部变化时依旧能够稳定运行。六边形架构将系统分为内六边形和外六边形两层这两层的职能划分如下红圈内的六边形实现应用的核心业务逻辑外六边形完成外部应用、驱动和基础资源等的交互和访问对前端应用以 API 主动适配的方式提供服务对基础资源以依赖倒置被动适配的方式实现资源访问。六边形架构的一个端口可能对应多个外部系统不同的外部系统也可能会使用不同的适配器由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。三种微服务架构模型的对比和分析DDD 分层架构、整洁架构、六边形架构虽然表现形式不同但设计思想一致都是微服务架构高内聚低耦合原则的体现。高内聚是把相关功能和数据集中成独立模块专注特定任务低耦合则是减少模块间依赖增强系统灵活性和可维护性。这三种架构通过不同方式达成模块独立与依赖弱化使各部分协同工作。它们还都以领域模型为中心。领域模型是业务核心知识的抽象是架构基石。围绕它不同架构搭建起交互和业务逻辑处理体系保障核心业务稳定运行为微服务架构搭建提供支撑观察图示可以发现DDD 分层架构、整洁架构和六边形架构虽呈现形式各异但存在显著的共性。三种架构中都有红色线框作为重要分界线其关键作用是将核心业务逻辑与外部应用、基础资源相互隔离。在红色框内部虽都实现核心业务逻辑然而其中业务逻辑存在功能差异。基于这种差异三种架构划分出应用层和领域层分别承担不同类型的业务逻辑。领域层作为原子模型面向领域模型实现领域模型的核心业务逻辑。它处于架构的核心位置需维持领域模型和业务逻辑的稳定性对外提供稳定的细粒度领域服务。这是因为在企业运营中只要没有大的变革核心领域逻辑基本保持稳定。应用层面向用户操作相关的用例和流程就像一个配速齿轮处于前台应用和领域层之间。它对外提供粗粒度的 API 服务负责接收前台需求随时做出响应与调整尽可能避免将前台需求直接传导至领域层。通过服务组合和编排应用层能快速适配业务流程并上线以应对用户体验、操作习惯、市场环境以及管理流程等变化所导致的界面逻辑和流程的多变。总体而言这三种架构充分考虑了前端需求的多变性与领域模型的相对稳定性。通过分层设计有效控制需求变化从外到里对系统的影响使面向用户的前端能灵活快速响应外部需求进行调整和发布同时让领域层保持长期稳定。这种设计对于构建前台灵活、中台稳固的架构大有裨益。看到这里相信大家对中台和微服务设计的关键已经有所思考。在我看来答案是领域模型和微服务的合理分层设计那么你心中的答案又是什么呢从三种架构模型看中台和微服务设计前文提到的 DDD 分层架构、整洁架构和六边形架构虽然外在表现形式不同但它们有着显著的共性。这三种架构都利用红色线框这样的重要分界线将核心业务逻辑与外部应用、基础资源隔离开来并且都划分出应用层和领域层通过不同的功能定位来应对前端需求的多变和领域模型的相对稳定。基于这些架构模型的共性我想谈谈关于中台和微服务设计的一些心得体会。中台从本质上来说是领域的子域它既可能是关乎业务核心的核心域也可能是提供通用能力的通用域或是起到支撑作用的支撑域。以阿里中台为例很多人认为它对应 DDD 中的通用域其作用是将通用的公共能力进行沉淀进而对外提供通用共享服务 。中台作为子域还具备进一步细化的空间能够继续分解为子子域。当子域被分解到合适的规模后通过事件风暴划分限界上下文就可以着手定义微服务了。微服务的作用就是实现中台的能力它把中台的复杂功能拆解成一个个小型、独立的服务以便更灵活高效地运行。乍看之下DDD、中台和微服务这三者之间似乎没有明显的联系但实际上它们的关系极为紧密。DDD 提供了领域驱动的设计理念帮助我们更好地理解业务领域中台作为业务能力的沉淀和共享平台是实现业务复用和快速响应变化的关键微服务则以其独立部署、灵活扩展的特性支撑着中台能力的具体实现。这三者相互配合共同构成了一个完整的理论体系为中台和微服务设计提供了有力的指导。中台建设要聚焦领域模型中台在企业架构中占据着关键地位它需要从全企业的宏观视角出发充分考量能力的共享与复用。中台设计绝非简单任务它要求我们构建中台内所有限界上下文的领域模型。在运用 DDD 进行建模的过程中不仅要深入剖析业务逻辑还需前瞻性地考虑架构的未来演进方向以及功能在不同场景下的重新组合。这一领域模型的构建过程犹如一场精密的手术会对业务与应用进行清晰的逻辑和物理边界划分而这些边界往往与微服务的架构紧密相关。领域模型一旦确立其影响力将贯穿整个系统开发流程。它如同基石直接作用于后续的系统模型、架构模型以及代码模型的构建。从更实际的角度来看领域模型的质量和合理性最终会深刻影响微服务的拆分策略和项目的落地实施。倘若领域模型构建不完善微服务拆分可能缺乏合理性导致服务之间的协作出现问题影响系统的整体性能和稳定性。而一个优秀的领域模型能为微服务拆分提供科学依据确保各个微服务既具备独立性又能高效协同工作助力项目顺利落地。由此可见在中台设计的复杂体系中领域模型应被置于核心位置。我们必须聚焦领域模型的构建投入足够的时间和精力为中台乃至整个企业的数字化架构奠定坚实基础。微服务要有合理的架构分层微服务设计需秉持分层思想使各层明确分工构建松耦合的层间关系。领域层应专注实现领域逻辑杜绝无关逻辑混入以维护其纯洁性与稳定性防止领域模型被污染。同时也不能将领域模型的业务逻辑置于应用层否则会使应用层臃肿导致领域模型失焦。若难以避免逻辑交叉可引入防腐层用于新老系统的适配与转换待过渡期结束后便可舍弃其代码。清楚了微服务内部的分层方式后再来看看微服务之间的关系。微服务之间存在层次依赖关系并且在服务集成上也有不同方式。比如项目级微服务可与前端应用集成共同完成特定业务而企业级中台微服务职责单一需多个此类微服务组合才能完成企业级业务流程。由于复杂度不同这两类微服务的集成方式也有所差异 。项目级微服务项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现服务的组合和编排在应用层实现通过 API 网关为前台应用提供服务实现前后端分离。但项目级的微服务可能会调用其它微服务你看在下面这张图中比如某个项目级微服务 B 调用认证微服务 A完成登录和权限认证。通常项目级微服务之间的集成发生在微服务的应用层由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中红色框内的应用服务 B它除了可以组合和编排自己的领域服务外还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用这样前端就可以直接访问自己的微服务了。企业级中台微服务在企业级业务流程中往往需要多个中台微服务协同工作那么跨中台的微服务该如何实现集成呢要知道企业级中台微服务的集成与项目级微服务不同无法在单个微服务内完成跨微服务的服务组合与编排。为了解决这个问题我们可以在中台微服务之上新增一层。从下方图示中可以看到新增的这一层位于红色框内它承担着关键职能。一方面负责处理跨中台微服务的服务组合和编排以及协调各微服务之间的工作另一方面还能够完成前端不同渠道应用的适配。如果进一步拓展其业务范围我们完全可以将它打造成一个面向不同行业和渠道的服务平台。这里我们借用 “BFF服务于前端的后端Backend for Frontends” 一词暂且称它为 BFF 微服务。BFF 微服务与其他普通微服务有着显著差异它没有领域模型相应地这个微服务内也就不存在领域层。BFF 微服务主要承担应用层和用户接口层的职能能够高效地完成各个中台微服务的服务组合和编排并且可以灵活适配不同前端和渠道的多样化要求为企业级业务流程的顺利开展提供有力支持应用和资源的解耦与适配在传统以数据为中心的设计模式下应用与数据库、缓存、文件系统等基础资源之间存在着紧密的依赖关系。这种强依赖意味着一旦基础资源发生变动例如更换数据库应用就会受到极大的冲击可能导致功能异常、运行效率降低甚至系统崩溃。为了改变这一现状实现应用与资源的解耦显得尤为重要。在微服务架构中应用层、领域层和基础层通过仓储模式运用依赖倒置的设计方法达成解耦。仓储模式就像是在应用与基础资源之间搭建了一座桥梁它抽象出对基础资源的访问操作使得应用层和领域层无需直接与具体的基础资源交互。依赖倒置则让高层次的模块不依赖于低层次模块的具体实现细节而是依赖于抽象接口。在应用设计阶段同步考虑与基础资源的代码适配工作能够有效屏蔽资源变更对业务代码的影响。当基础设施资源发生变更时只需在仓储层对相关接口实现进行调整业务逻辑代码无需改动从而成功切断业务逻辑对基础资源的依赖将资源变更给应用带来的影响降至最低。这种设计不仅提升了应用的稳定性和可维护性还为系统的持续发展和升级提供了有力保障 。最后的最后感谢你们的阅读和喜欢作为一位在一线互联网行业奋斗多年的老兵我深知在这个瞬息万变的技术领域中持续学习和进步的重要性。为了帮助更多热爱技术、渴望成长的朋友我特别整理了一份涵盖大模型领域的宝贵资料集。这些资料不仅是我多年积累的心血结晶也是我在行业一线实战经验的总结。这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。如果你愿意花时间沉下心来学习相信它们一定能为你提供实质性的帮助。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】大模型知识脑图为了成为更好的 AI大模型 开发者这里为大家提供了总的路线图。它的用处就在于你可以按照上面的知识点去找对应的学习资源保证自己学得较为全面。经典书籍阅读阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。实战案例光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。面试资料我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】