text: 互联网主流微服务架构模型对比分析
  整洁架构 又名“洋葱架构”(看图就懂)，体现了分层思想。
  同心圆代表应用软件的不同部分，由内到外依次是
  容易变化的内容
  该架构最主要原则:依赖原则，它定义了各层依赖关系，越往内依赖越低，代码级别越高，能力越核心。
  职能划分 领域模型
  实现领域内核心业务逻辑，封装了企业级业务规则。
  主要提供适配的能力，分为主动适配和被动适配。
  主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配
  红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
  六边形架构 又名“端口适配器架构”。
  应用通过端口与外部交互
  红圈内的核心业务逻辑(应用程序和领域模型)与外部资源(包括APP、Web应用以及数据库资源等)完全隔离，仅通过适配器交互。
  职能划分 系统分为内六边形和外六边形:红圈内六边形
  实现应用的核心业务逻辑
  外六边形
  完成外部应用、驱动和基础资源等的交互和访问，对前端应用以API主动适配方式提供服务，对基础资源以依赖反转被动适配的方式实现资源访问
  这就使得应用程序能够以一致的方式被用户形式使用。
  现在，很多声称使用分层架构的团队实际上使用的是六边形架构。
  架构模型对比分析 虽然DDD分层架构、整洁架构、六边形架构的架构模型表现形式不同，但设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。
  红框内部主要实现核心业务逻辑，但核心业务逻辑也有差异，有属于领域模型，有属于面向用户的用例和流程编排能力。
  领域层 实现面向领域模型，实现领域模型的核心业务逻辑，属原子模型，需保持领域模型和业务逻辑稳定，对外提供稳定的细粒度领域服务，所以是架构核心。
  应用层 实现面向用户操作相关的用例和流程，对外提供粗粒度API服务。
  这三种架构都考虑了前端需求的变与领域模型的不变 。
  架构模型通过分层控制需求变化从外到里对系统影响，从外向里受需求影响逐步减小。
  这样设计的好处 ，可保证领域层核心业务逻辑不会因外部需求和流程的变动而调整。
  从三种架构模型看中台和微服务设计 中台本质是领域的子域，它可能是核心域，也可能是通用域或支撑域。
  中台建设要聚焦领域模型 中台需考虑能力的共享和复用。
  要建立中台内所有限界上下文的领域模型，DDD建模过程中会考虑架构演进和功能的重新组合。
  领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界(微服务)划分。
  保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。
  项目级微服务
  项目级微服务的内部遵循分层架构模型即可。
  通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在API网关上的应用服务。
  企业级中台微服务
  再将它的业务范围扩大一些，可做成一个面向不同行业和渠道的服务平台。
  借用BFF(服务于前端的后端，Backend for Frontends)词。
  应用和资源的解耦与适配 传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
  一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。
  在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的。
  相关文章常见互联网业务模型与架构浅析
  敏捷大数据方法论 大数据文摘 关于未来十年企业架构的十个关键词 大数据文摘 几种经典的网络服务器架构模型的分析与比较 前言
  大家下午好，我是普元的邓通，之前在群里分享过《企业数字化转型实战:红领酷特智能C2M商业生态》，非常高兴今天再次在这里和大家交流。
  程序猿DD 中小团队开始回归单体架构，那么电信运营商该不该用微服务
  深度学习与Python 进阶Java架构师必看的15本书 1、大型网站技术架构:核心原理与案例分析
  这是一个务实的很好的方向，相对于旧的宏服务来说。