A1 · 架构风格

架构风格：一题多说法

同一套协会平台，题干怎么换措辞，你就怎么换构件与连接件的名字

一句话：架构风格是一套词汇表。软考近九年考了云原生、微服务、面向服务、 事件驱动、无服务器、六边形、分层、Lambda、模型驱动、边缘计算十种风格， 题干措辞各异，考的都是用这套词汇把同一个项目讲清楚。 练法只有一种：一套架构事实，多套说法。
① 会考什么

会考什么

架构风格/模式是九年内每年必出的主题，权重最高。下面是历年架构风格题干节选（逐字摘句）；本页是风格清单，完整题干与三问见各风格对应年份的真题原文。

2020 · 试题三 · 论云原生架构及其应用 服务化、弹性、可观测性和自动化是云原生架构的四类设计原则，请简要对这四类设计原则的内涵进行阐述。
2021 · 试题四 · 论微服务架构及其应用 请围绕"论微服务架构及其应用"论题，依次从以下三个方面进行论述。
2022 · 试题四 · 论湖仓一体架构及其应用 支持事务一致性、提供高并发实时处理及分析能力的湖仓一体（Lake House）架构应运而生。
2023 · 试题四 · 论边缘计算及其应用 边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的分布式开放平台（架构），就近提供边缘智能服务。
2024上 · 试题一 · 论大数据Lambda架构及其应用 Lambda体系结构将数据流分为三个层次：批处理层（batch layer）、加速层（speed layer）和服务层（serving layer），请简要分析这三个层次的特性和用途。
2024上 · 试题二 · 论模型驱动架构设计方法及其应用 模型驱动架构设计是一种用于应用系统开发的软件设计方法，以模型构造、模型转换和精化为核心，提供了一套软件设计的指导规范。
2024下 · 试题二 · 论面向服务的架构设计 论面向服务的架构设计基于WebService的面向服务架构实现过程，SOA具有哪些特征，支撑软件功能重用。
2025上 · 试题一 · 论事件驱动架构及应用 事件驱动架构（Event-Driven Architecture，EDA）是一种以事件为核心的软件架构模式，强调通过事件的产生、检测、消费和响应来实现系统各组件之间的松耦合通信。
2025下 · 试题一 · 论无服务器架构（Serverless） Serverless架构模式（无服务器架构）通过"函数即服务（FaaS）"与"后端即服务（BaaS）"的核心理念，实现了"按需分配资源、按使用付费、无需关注底层运维"的核心价值，……
2026上 · 试题三 · 论六边形架构的设计与应用 简述基于六边形架构思想的软件分析、设计和开发全流程。

考过哪些风格 / 各考过几次

风格真题出处本页是否主线
云原生架构2020 试题三主线
微服务架构2021 试题四主线
湖仓一体2022 试题四数据类，见 D 系列
边缘计算2023 试题四降权（9 年 1 次）
Lambda 大数据架构2024上 试题一数据类，见 D 系列
模型驱动架构 MDA2024上 试题二开发方法，见 A 系列
面向服务架构 SOA2024下 试题二主线（并入服务化）
事件驱动架构 EDA2025上 试题一主线
无服务器 Serverless2025下 试题一主线（并入云原生）
六边形架构2026上 试题三主线（降权保留）
分层架构通用基础风格主线（其余风格的底座）
口径：「架构风格/模式」九年内考了 10+ 次，每年必有； 2026上 刚考过六边形，按"考试会避开重复"降权保留，不作为下一场首选，但必须能说清。
② 一句话讲清

一句话讲清

TL;DR：一套架构事实，换一套构件与连接件的名字。 分层叫「表现层/业务层/数据层」，六边形叫「端口/适配器」，事件驱动叫「生产者/事件通道/消费者」—— 同一个咨询请求，换个词就是另一个答案。
③ 机制讲解

机制讲解：同一个请求，六种走法

下面固定一个请求——会员提交一个法律咨询问题——然后用六种架构风格分别走一遍。 切换风格看路径怎么变，再切到「不这么做会怎样」看这条路走歪了长什么样。

请求流动路径对比

点风格切换走法；点右上角切「规范做法 / 不这么做会怎样」

请求：POST /api/consult — 会员提交法律咨询问题
这六种走法的本质差别是什么

六个按钮背后只有三个变量在动：

  • 依赖方向——分层是「上层依赖下层」，六边形是「所有依赖指向领域核心」，两者恰好相反。
  • 同步还是异步——事件驱动把非必需的下游从主链路里摘出去，其余五种默认同步。
  • 边界切在哪——微服务按限界上下文切、SOA 按可复用服务切、管道-过滤器按处理步骤切。

答题时只要抓住这三个变量，题干用哪种措辞都能对号入座： "解耦"问的是依赖方向，"松耦合/削峰"问的是同步异步，"拆分/复用"问的是边界切法。

④ 落到我们平台

落到我们平台

fazi 协会平台不是"选一种风格"，而是分层作底座、六边形作骨架、事件驱动作补充， 题干问哪种就放大哪种。对应关系：

题干风格对应 fazi 的哪个模块什么取舍
分层Nuxt 4 表现层 / Go 业务层 / PostgreSQL 数据层换实现不动其他层，代价是多一层跳转
六边形（端口-适配器）法律咨询域核心 + Gin 入站适配器 + pgx / 大模型出站适配器核心可单测，代价是端口与适配器样板代码
事件驱动电子存证哈希回填、培训报名余票通知、问答反馈采集主链路不与下游耦合，代价是消费者幂等要自己做
微服务 / SOA会员 / 内容 / 存证 / 培训 / 咨询五个限界上下文边界清晰、可独立扩容，代价是一人全栈下的部署与联调负担
云原生 / Serverless云托管容器服务、无状态服务、弹性伸缩不运维中间件，代价是受云厂商能力边界约束
管道-过滤器法律问答 RAG 链路：切分 → 向量化 → 检索 → 重排 → 生成每段可单独替换与调优，代价是链路长、端到端调参
红线：平台技术栈只有 Nuxt 4 SSR、Go 1.26 + Gin + pgx、PostgreSQL 18 + pgvector、云托管容器服务。 没有消息中间件、没有服务网格、没有容器编排平台—— 事件驱动就用 PostgreSQL 的 outbox 表 + LISTEN/NOTIFY 实现， 服务化就靠"逻辑分服务、物理同镜像"。写机制时不许出现栈里没有的组件。
⑤ 完整论文

完整论文

摘要 + 一至六段全文。粗体标题是软考要求的段名；点每段可看逐段拆解。

展开全文（摘要 + 六段）

摘要

2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。
本文以该项目为例，讨论了架构风格与方法在实际项目中的应用。文章首先介绍项目背景和架构风格与方法的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。
通过架构风格与方法的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。

一、项目背景

河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。

二、理论概述

架构风格是对一类系统结构组织方式的抽象，它规定了构件、连接件以及二者之间的配置规则，可以理解为架构设计的词汇表。业界通常把架构风格分为五类：数据流风格，如管道-过滤器；调用返回风格，如分层；独立构件风格，如事件驱动；虚拟机风格，如解释器；仓库风格，如数据库。面向对象、微内核、面向服务、云原生等，则可视为这些风格在工程实践中的延伸。
本题考察的不是背定义，而是用不同风格的语言重述同一套架构的能力。近九年考过云原生、微服务、面向服务、事件驱动、无服务器、六边形等十余种风格，题干措辞各不相同，但考察对象都是同一件事：能否用该风格的构件与连接件，把项目讲清楚、讲扎实。
对协会平台，我始终用三种风格描述它。一是分层风格，前端表现层、Go 业务层、PostgreSQL 数据层各司其职，上层只调用下层；二是六边形风格，把法律咨询、电子存证、培训报名等业务规则收敛为领域核心，通过入站端口与出站端口同外部解耦；三是事件驱动风格，把存证回填、报名通知等非实时链路异步化。换一种风格措辞，只需替换构件与连接件的名字，架构本体保持不变。

三、实践一：分层与六边形落地

平台选型时，我首先确定分层与六边形相结合的整体风格。分层解决职责划分，Nuxt 4 SSR 承担表现层渲染与 SEO，Go 1.26 加 Gin 承担业务层，PostgreSQL 18 加 pgvector 承担数据层，层间只允许上层调用下层，禁止表现层跨层直连数据库。
六边形解决依赖方向。我把法律问答、电子存证、培训报名三块业务规则收敛为领域核心，核心不引用任何 Web 框架与数据库驱动。核心对外定义入站端口与出站端口：入站端口由 HTTP 处理器和定时任务入口适配，出站端口由 pgx 访问 PostgreSQL、由适配器调用大模型接口来实现。这样领域核心只依赖端口接口，更换向量库或大模型时只需替换出站适配器，业务规则一行不改。
遇到的问题是可测试性差。改造前业务逻辑直接写在 Gin 处理器里，与 HTTP 上下文耦合，无法独立单测，每次回归都要起完整数据库。按端口-适配器重构后，领域逻辑以接口加纯函数的形式存在，用内存适配器即可在无数据库环境跑通单元测试，回归速度明显提升，也让六边形架构的价值在项目里真正落地。

四、实践二：事件驱动解开主链路

第二种风格是事件驱动。平台有三条链路不需要同步返回：电子存证的文件哈希回填、培训报名的余票通知、法律问答的用户反馈采集。如果用同步调用把它们串起来，用户请求就要等待多个下游，任一环节变慢都会直接拖长响应时间，下游故障还会传播成请求失败。
我在 PostgreSQL 18 上实现事件驱动，不引入消息中间件。业务数据与事件在同一事务写入 outbox 表，保证业务与事件的一致性；消费者进程用 LISTEN/NOTIFY 监听事件表，收到通知后异步处理并回写状态。事件生产者与消费者只依赖事件结构，彼此不感知对方的存在，新增消费者不必改动生产者。
挑战是重复消费。NOTIFY 不保证恰好一次投递，消费者可能因重试而重复处理。我给每个消费者维护一张事件处理记录表，以事件 ID 做幂等去重，落库时再用唯一约束兜底。这样即使消费者重启重放，也不会重复扣减培训名额或重复发送通知。异步化之后，主链路响应不再受下游波动影响，三条链路的问题都被隔离在各自的消费者内。

五、实践三：服务化与云原生

第三种风格是云原生与服务化。若题干问微服务或面向服务，我就按此展开：我以领域驱动设计的限界上下文为依据，把平台划分为会员、内容、存证、培训、咨询五个可独立演进的模块，各自拥有独立的数据表与 API，模块之间只通过接口通信，不共享数据库表。
挑战是服务粒度与运维成本。一人全栈下，拆得过细会让部署与联调负担剧增。我的做法是逻辑上分服务、物理上同镜像：代码按限界上下文分包，按模块拆分路由与数据访问，初期以一个容器镜像部署，按需水平扩容；只有在性能或团队边界确实需要时，才拆为独立部署单元。服务全部无状态，会话与文件放在 PostgreSQL 与对象存储，依托云托管容器服务做滚动发布与弹性伸缩，不再自建中间件。
效果上，架构收敛后平台于 2026 年 6 月上线，法律问答 Recall@20 达 0.92，P95 响应 380 毫秒，可用性 99.95%，MTTR 从 45 分钟降至 8 分钟。三种风格叠加的收益是清晰的：分层让代码可维护，六边形让核心可测试，事件驱动让主链路不被下游拖累，服务化让容量可以按模块扩展。

六、总结展望

本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
架构风格的价值在于统一语言。未来，我将继续以分层、六边形与事件驱动三种风格为主线，沉淀协会平台的架构基线，让同一套系统在不同考题下都能被准确、一致地表述。
⑥ 逐段拆解

逐段拆解

段讲什么字数
摘要项目一句话 + 本文结构 + 效果数据307 纯汉字
一、项目背景协会现状、我的职责、技术栈、三个关键决策（定稿逐字抄）459 定稿
二、理论概述架构风格五分类 + 本题考法（一题多说法）+ 平台用哪三种风格417
三、实践一分层定职责、六边形定依赖方向；问题=可测试性，方案=端口-适配器重构353
四、实践二事件驱动三链路；用 outbox + LISTEN/NOTIFY 落地；挑战=重复消费，方案=幂等表361
五、实践三限界上下文五模块；挑战=粒度与运维成本，方案=逻辑分服务物理同镜像；效果数据364
六、总结展望取舍总结 + 三条不足改进 + 架构风格=统一语言（定稿 + 主题句）265

每段都只干一件事：理论段不含项目细节，实践段不重复定义。 三段实践的骨架完全一致——先讲做法、再讲遇到的问题、最后给出措施与结果， 这是阅卷最认的结构。

⑦ 答题要点

答题要点

题干三问对应本文哪段：以 2026上 试题三《论六边形架构的设计与应用》为例。
第 1 问「概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。」→ 本文第一段。
第 2 问「简述基于六边形架构思想的软件分析、设计和开发全流程。」→ 本文第二段（风格分类与考法）， 六边形全流程在 第三段展开（领域核心收敛 → 入站与出站端口定义 → 适配器设计 → 端口-适配器重构后可单测）。
第 3 问「结合项目，阐述如何进行图数据设计。」→ 本文 P2–P5 无对应材料，见下方缺口。
缺口（标红）：2026上 试题三 第 3 问考的是图数据设计，本文 P2–P5 无对应材料—— 第二段是风格分类、第三段是端口-适配器、第四段是事件驱动、第五段是服务化与云原生，都没有图数据设计。 考到这问必须另备一段：用 PostgreSQL 18 邻接表存顶点与边、递归 CTE 查关联路径、pgvector 做向量近邻， 并说清顶点、边、标签、约束、索引与典型遍历查询；图结构只作出站适配器，领域核心不依赖具体图库 SDK。

✅ 加分

❌ 扣分

⑧ 背诵清单

背诵清单

  1. 架构风格是一套词汇表：构件、连接件、配置规则三要素。
  2. 五分类：数据流、调用返回、独立构件、虚拟机、仓库。
  3. 分层管职责，六边形管依赖方向，事件驱动管同步异步——三者正交，可叠加。
  4. 六边形一句话：所有依赖指向领域核心，外部全走端口与适配器。
  5. 事件驱动落地一句话：业务与事件同事务进 outbox，LISTEN/NOTIFY 异步消费，按事件 ID 幂等去重。
  6. 服务化落地一句话：按限界上下文逻辑分服务，物理同镜像，状态外置到 PG 与对象存储。
  7. 一题多说法：同一套架构事实，换题干就换构件与连接件的名字，架构本体不动。
  8. 三段实践统一骨架：做法 → 问题 → 措施与结果。
⑨ 数据来源

数据来源

数据来源口径
可用性 99.95%论文口径固化取值
MTTR 45 → 8 分钟论文口径固化取值
Recall@20 0.92、P95 380ms、缓存命中率 92%论文承诺口径（essay-common.md 已固化）成文取值，非本页实测
③ 六种风格的流动路径、依赖方向、同步异步架构机制演示，无性能数字定性演示
本页无独立实验场，不提供任何实测数字。 论文中的运营与技术指标均来自 docs/essay-common.md 的固化口径； 不得在本页出现的机制描述里新增没测过的数字。 ③ 模拟器只演示"路径与依赖方向"，不含任何性能数据。