国王小组:国际多语言交易所搭建|如何选择开发架构风格

简介: DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定。

国王小组:国际多语言交易所搭建|如何选择开发架构风格
DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定。

核心的指导思路归纳为:

关注点放在domain上,将业务领域限定在同一上下文中

降低上下文之间的依赖,通过‘开发主机服务’(REST服务是其中的一种)、‘消息模式’、‘事件驱动’等架构风格实现

遵循分层架构模式

架构风格

针对DDD的架构设计,《实现领域驱动设计》提到了几种架构风格:六边形架构、REST架构、CQRS、事件驱动等。在实际使用中,落地的架构并非是纯粹其中的一种,而很有可能户将上述几种架构风格结合起来实现。

此部分内容主要来源于《实现领域驱动设计》的第4章,加上了自己的一些理解。

六边形架构(端口和适配器)

所谓的六边形架构,其实是分层架构的扩展,原来的分层架构通常是上下分层的,比如常见的MVC模式,上层是对外的服务接口,下层是对接存储层或者是集成第三方服务,中层是业务逻辑层。我们跳出分层的概念,会发现上面层和下面层其实都是端口+适配器的实现,上面层开放http/tcp端口,采用rest/soap/mq协议等对外提供服务,同时提供对应协议的适配器;下层也是端口+适配器,只不过应用程序这时候变成了调用者,第三方服务或者存储层提供端口和服务,应用程序本身实现适配功能。

基于上述思考,将分层接口中的上层和下层统一起来就变成了六边形架构,基于端口和适配器的实现,示意图如下:

上图来源于《实现领域驱动设计》的P111

我认为六边形架构并非创造一种新的架构风格,只是将原来的分层架构风格重新解读,使得架构更加简洁通用。同时,在DDD的设计思想下,六边形架构风格,让领域模型处于架构的核心区域,让开发人员将焦点聚集到领域。DDD和六边形架构是天然契合的,是DDD的首选架构。

REST

REST——即Representational State Transfer的缩写,翻译过来是"表现层状态转化"。参考至:理解RESTful架构。

RESTful风格的架构将‘资源’放在第一位,每个‘资源’都有一个URI与之对应,可以将‘资源’看着是ddd中的实体;RESTful采用具有自描述功能的消息实现无状态通信,提高系统的可用性;至于‘资源’的哪些属性可以公开出去,针对‘资源’的操作,RESTful使用HTTP协议的已有方法来实现:GET、PUT、POST和DELETE。

在DDD的实现中,我们可以将对外的服务设计为RESTful风格的服务,将实体/值对象/领域服务作为'资源'对外提供增删改查服务。但是并不建议直接将实体暴露在外,一来实体的某些隐私属性并不能对外暴露,二来某些资源获取场景并不是一个实体就能满足的,因此我们在实际实践过程中,在领域模型上增加了dto这样一个角色,dto可以组合多个实体/值对象的资源对外暴露。

CQRS

CQRS——Cammand-Query Responsibility Segregation的缩写。翻译过来就是“命令与查询职责分离”。

简而言之,CQRS就是平常大家在讲的读写分离,通常读写分离的目的是为了提高查询性能,同时达到读/写的解耦。让DDD和CQRS结合,我们可以分别对读和写建模,查询模型通常是一种非规范化数据模型,它并不反映领域行为,只是用于数据显示;命令模型执行领域行为,且在领域行为执行完成后,想办法通知到查询模型。

那么命令模型如何通知到查询模型呢? 如果查询模型和领域模型共享数据源,则可以省却这一步;如果没有共用数据源,则可以借助于‘消息模式’(Messaging Patterns)通知到查询模型,从而达到最终一致性(Eventual Consistency)。

Martin在blog中指出:CQRS适用于极少数复杂的业务领域,如果不是很适合反而会增加复杂度;另一个适用场景为获取高性能的服务。

    图片来源于Martin Fowler的blog,图中表述的查询模型和命令模型共用数据源。

关于CQRS的讨论可以参考Martin大叔的blog:CQRS,以及:CQRS, Task Based UIs, Event Sourcing agh!

事件驱动

 这一架构风格在实际项目中并未使用,不做过多阐述,感兴趣的同学自行研究。

架构实例

结合最近在重构的社区服务系统(ECO),尝试使用上述的指导思想和架构风格,完成一次架构设计尝试,并详述如下:

架构图

架构详述

ECO系统架构整合了六边形架构、RESTful架构风格、CQRS架构风格三种架构风格,并遵循经典的分层架构思想。

1、在遵循分层架构思想的基础上,引入了六边形架构风格,对内对外均通过适配器+端口的方式呈现:

面向用户侧,提供http端口,并使用SpringMVC框架的RequestMapping、Controller等组件实现对http 请求的解析,转化为Application层可识别的业务dto对象,这里的Controller+RequestMapping便起着适配器的作用;

面向第三方服务,通过httpclient和tcpclient的适配,可以对接多种协议的第三方服务端口;

面向存储层,通过mongoclient的适配,访问mongodb;通过mybatis的适配,访问oracle;通过redisclient的适配,访问redis;

面向消息中间件,通过mqclient的适配,方为rabbitMQ;

2、实现了RESTful架构风格,通过RESTful风格的接口契约对外提供主机开放服务。借助SpringMVC实现。

3、实现了CQRS架构风格:

orcale作为命令模型存储存在,并配以Transaction事务管理。主要存储帖子、评论、话题、圈子、关注等实体信息;

Mongodb作为查询模型存储存在,存储个人动态、社区动态等非结构化数据;

redis同样作为查询模型存储存在,存储用户个人信息、热门评论、热门帖子、热门话题、用户点赞信息等;

Application层分为QueryService和CommandService两大类应用服务,分别组合查询模型和命令模型;

使用rabbitMQ作为消息中间件,CommandService在完成命令模型的维护后,生产事件消息写入rabbitMQ,QueryService作为消费者从rabbitMQ读取事件消息,更新查询模型;

查询模型和命令模型极其对应的application service可以独立部署,独立扩展。

4、遵循基本的分层架构风格。

User Interface —— 用户接口层。对外提供各种协议形式的服务,并提供Validation参数校验,authenticate权限认证,业务实体组装器Assembler等。图中标绿组件。

Application —— 应用服务层。组合多个业务实体、基础设施层的各种组件完成业务服务。图中标黄部分。

Domain —— 业务领域层。DDD概念中的核心业务层,封装所有业务逻辑,包含entity、value object、domain service、domain event等。图中标蓝部分。

Infrastructure —— 基础设施层。提供公共组件,如:Logging、Trascation、HttpClient等。图中标灰部分。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
21天前
|
API 持续交付 开发者
后端开发中的微服务架构实践与挑战
在数字化时代,后端服务的构建和管理变得日益复杂。本文将深入探讨微服务架构在后端开发中的应用,分析其在提高系统可扩展性、灵活性和可维护性方面的优势,同时讨论实施微服务时面临的挑战,如服务拆分、数据一致性和部署复杂性等。通过实际案例分析,本文旨在为开发者提供微服务架构的实用见解和解决策略。
|
5天前
|
消息中间件 监控 持续交付
后端开发中的微服务架构设计与实践####
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用的关键策略。本文将深入探讨微服务架构的核心概念、设计原则与实战技巧,通过实例解析如何在后端开发中有效实施微服务,以应对复杂业务需求和技术挑战。我们将从微服务的拆分策略、通信机制、数据管理到持续集成/持续部署(CI/CD)流程,全面剖析其背后的技术细节与最佳实践,为读者提供一份详尽的微服务架构设计与实践指南。 ####
|
15天前
|
监控 API 持续交付
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势、面临的挑战以及最佳实践策略。不同于传统的单体应用,微服务通过细粒度的服务划分促进了系统的可维护性、可扩展性和敏捷性。文章首先概述了微服务的核心概念及其与传统架构的区别,随后详细阐述了构建微服务时需考虑的关键技术要素,如服务发现、API网关、容器化部署及持续集成/持续部署(CI/CD)流程。此外,还讨论了微服务实施过程中常见的问题,如服务间通信复杂度增加、数据一致性保障等,并提供了相应的解决方案和优化建议。总之,本文旨在为开发者提供一份关于如何在现代后端系统中有效采用和优化微服务架构的实用指南。 ####
|
17天前
|
消息中间件 设计模式 运维
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,通过实际案例分析,揭示了其在提升系统灵活性、可扩展性及促进技术创新方面的显著优势。同时,文章也未回避微服务实施过程中面临的挑战,如服务间通信复杂性、数据一致性保障及部署运维难度增加等问题,并基于实践经验提出了一系列应对策略,为开发者在构建高效、稳定的微服务平台时提供有价值的参考。 ####
|
17天前
|
消息中间件 监控 数据管理
后端开发中的微服务架构实践与挑战####
【10月更文挑战第29天】 在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用程序的首选方案。本文探讨了微服务架构的核心概念、实施策略以及面临的主要挑战,旨在为开发者提供一份实用的指南,帮助他们在项目中成功应用微服务架构。通过具体案例分析,我们将深入了解如何克服服务划分、数据管理、通信机制等关键问题,以实现系统的高可用性和高性能。 --- ###
38 2
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
11天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
11天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
28 1
服务架构的演进:从单体到微服务的探索之旅
|
9天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
27 8
|
10天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
35 5
下一篇
无影云桌面