网站做分屏好不好,php mysql网站开发教程,wordpress投稿图片大小,阳江市商品房备案查询无论是单体应用还是微服务#xff0c;构建企业应用的业务逻辑/服务在更多方面上都有相似之处而不是差异。在两种方法中#xff0c;都包含服务、实体、仓库等类。然而#xff0c;也会发现一些明显的区别。在本文中#xff0c;我将试图以概念性的方式强调这些区别#xff0c… 无论是单体应用还是微服务构建企业应用的业务逻辑/服务在更多方面上都有相似之处而不是差异。在两种方法中都包含服务、实体、仓库等类。然而也会发现一些明显的区别。在本文中我将试图以概念性的方式强调这些区别通过重新审视每种架构中内置的一些核心设计模式和原则。 那么让我们从“六边形架构”Hexagonal Architecture开始以及它与企业应用业务逻辑的关系。 六边形架构 任何企业应用中的业务服务理论上都在其核心使用了六边形架构 六边形架构/端口和适配器架构是一种用于软件架构设计的架构模式。它旨在创建松散耦合的应用组件可以通过端口和适配器与其软件环境轻松连接。维基百科 图01 — 六边形架构 如图01所示“业务服务逻辑”是六边形架构的核心。 领域模型模式 传统的过程式事务脚本模式通常是实现“简单业务逻辑”的一种很好的方式。 事务脚本模式将业务逻辑组织成一组每个类型请求一个的过程性事务脚本。 但是当实现“复杂业务逻辑”时应考虑使用领域模型模式**基本上是使用面向对象设计OOD。 领域模型模式将业务逻辑组织成一个对象模型其中包含具有状态和行为的类[1]。 领域驱动设计DDD 然而领域模型模式在典型的单体应用后端上效果良好但在微服务应用中有一定局限性这基本上由领域驱动设计DDD所覆盖。 DDD是对OOD的细化它是一种开发复杂后端业务逻辑的方法。 使用DDD时每个服务都有其自己的领域模型避免了整个应用程序的统一领域模型的问题。 战略模式与战术模式 DDD提出了多种战略模式和战术模式。 其中两个关键的战略模式是子域Subdomains和有界上下文Bounded Contexts。这些模式通常有助于在应用程序中分解业务逻辑。 根据Vaughn Vernon的《实现领域驱动设计》一书[5]子域存在于问题空间有界上下文存在于解决方案空间。 换句话说有界上下文帮助您管理应用程序中的复杂性而子域则有助于组织和管理业务域的不同方面。 在实践中有界上下文通常与一个子域对齐但也可能在单个子域内有多个有界上下文或者有一个跨越多个子域的有界上下文。 在每个有界上下文中我们可以建立专门负责各自领域的团队来进行管理。这些团队负责构建给定领域的构件、需求、规范和服务。 战术模式基本上是您在服务中定义的领域模型的构建块。其中一些战术设计模式是实体Entity、值对象Value Object、工厂Factory、仓库Repository、服务Service和聚合Aggregate。 在本文中我们将更深入地研究聚合模式及其在典型微服务设计中的用途。 聚合模式 聚合模式将一个领域模型组织为一组聚合每个聚合都是一个可以视为单元的对象图[1] 传统的领域模型是一个类和它们之间的关系的集合。在这个模型中所有类和关系都是相互关联的相对较难找到每个业务对象的边界这是复杂微服务设计的关键要求。DDD中的聚合模式可以帮助您解决这个问题。 在聚合模式中根据定义将领域模型结构化为一组聚合使其边界显式并更易于理解。 图02 — 具有聚合的领域模型 每个聚合都有一个根实体聚合根可能有一个或多个值对象。 但这并不意味着一个聚合只能有一个实体。您可以在一个聚合中有多个实 体。但最佳实践是在一个聚合内有最少数量的实体以提高每个事务的可扩展性。 聚合根是主要实体它保存对领域模型中其他聚合的引用并且是唯一一个可以用于直接查找的聚合中的实体。在聚合中的组件例如值对象将彼此间有对象引用。在图02中您将看到这一点每个引用的聚合主键ID都存储在主要聚合中即聚合01。这允许在领域模型内部实现更松散耦合的架构。 聚合通常是从数据库完整加载以避免任何延迟加载。即使在它被删除的同时聚合也会将其边界内的所有对象从数据库中移除。除此之外将它们存储在像MongoDB这样的NoSQL数据库中更加简单。 简而言之应用DDD聚合模式将 1.将服务中的领域模型模块化。2.消除服务之间的对象引用在DDD中不同聚合中的类之间的引用是基于主键值而不是对象引用。3.事务只能创建或更新单个聚合。这允许应用程序使用Saga模式更新多个聚合我在之前的博客文章中详细讨论了Saga模式。 聚合与Saga模式 Saga编排了一系列微服务中的本地事务以保持数据一致性。每个本地事务都与一个映射的聚合相关联参见图03。 图03 — 连接聚合模式和Saga模式 聚合与有界上下文 在技术理论上有关“有界上下文”和“聚合”之间的区别有一些误解。因此了解它们之间的区别及其与微服务的关联至关重要。 如前所述微服务可以通过“有界上下文”或“领域”来解释。每个“有界上下文”将有一个或多个“聚合”。 因此在实践中微服务不应小于一个聚合也不应大于一个有界上下文。 图04 — 有界上下文与聚合 领域事件模式 在概念上当聚合被创建和更新时它们会发布领域事件。聚合知道其状态何时发生变化因此知道要发布的事件。 这些领域事件最终作为消息发布到消息代理例如Kafka。 领域事件模式当聚合被创建并且经历某些其他重要变化时发布领域事件[1]。 事件风暴 有几种策略可以识别领域事件。其中一种流行的策略是事件风暴可以通过一种研讨会形式的安排来执行以了解具有许多事件的复杂领域。这种研讨会的最终结果是一个以事件为中心的领域模型其中包含聚合和事件。
