案例分析

质量属性 + 架构风格

性能 可修改性 可用性 ?? 安全性

论文预测

• 微服务架构
• 集成测试
• 论软件架构评估
• 数据共享架构
  • 放弃这个
• • 这个可以写

微服务架构 ★

写一下自己为什么采用微服务架构，微服务的优势是哪些方面，为什么要采用它。

克服的问题有哪些，是怎么解决的，技术选型是怎么考虑的，他们的优势和劣势，引入之后有没有遇到新的问题，是怎么解决的。

解决方案（推荐）

• 1、微服务间通信，采用了 SpringCloud Feign 组件
• 2、分布式事务（保证数据一致性）
• 3、系统安全性
  • 单点授权，身份认证，Gateway 网关
• 4、系统可靠性
  • 集群部署

集成测试

如果集成测试要这么写，那废了。

动态测试和静态测试

看起来也不好写。

论软件架构评估

【这个我不建议写，能编，但是挺难结合项目的】

架构权衡分析法（ATAM）确实是今年论文的高频备选方向之一。原因很简单——它是架构评估里的核心方法，还没被考“烂”，而且刚好能串联起这些阅卷人最看重的得分要素。

• “论软件系统架构评估——架构权衡分析法（ATAM）的应用”
• “结合项目实际，论述”
• 题目里会直接要求写出：质量属性、场景、效用树、风险点/敏感点/权衡点、评估阶段

ATAM 是什么

• ATAM是基于场景的架构评估方法，用于在多个质量属性之间进行权衡分析。
• 通过识别风险点、敏感点、权衡点，确认架构决策是否满足非功能需求。

明确项目里最重要的质量属性（至少写3-4个）

• 必写：性能、可用性、可修改性、安全性
• 每个属性用一句话定义，例如：
  • • 性能：系统对事件的响应速度。
  • • 可用性：故障恢复能力，比如X分钟内恢复。
  • • 可修改性：变更的成本，比如新增一个规则模块只需Y人天。

论领域驱动设计及其应用 ★

依赖关系（论文里必须写对的方向）

依赖方向（箭头表示“依赖于”）：

Controller/Trigger → Service → Domain ← Repository
                                    ↑
                              Repository接口定义在领域层
                              实现在基础设施层

系统采用DDD四层架构：用户接口层负责HTTP请求和MQ消息接入，应用层编排业务流程，领域层封装核心业务规则并定义仓储接口，基础设施层提供持久化实现。依赖方向严格向内，领域层作为核心不依赖任何外部框架，确保了业务逻辑的纯粹性和可测试性。

---