知识卡片
架构定义是问题域与解决方案域之间的桥梁
内容
需求分析只谈”要什么”，刻意忽略开发者、运维等人的约束；设计只谈”怎么实现”，假设需求已经确定好摆在面前。架构定义处在两者中间：既要理解所有关心架构的人（不只是用户）的真实需求，又要在技术可行性、时间、成本等约束下做出取舍并落地成结构。它的特殊之处在于覆盖的人群更广、考虑的问题更广（不只是功能），而且往往是一个”边发现边定义”的过程——利益相关者一开始通常只有模糊想法，而不是一份稳定的需求清单。
参考来源
- 位置：第5章《软件架构师的角色》5.1.1节「架构定义不仅是设计」（源文件：_epub-src/OEBPS/text00043.html附近）
- 结论依据：原文明确区分设计（专注解决方案域，只针对开发者，假设需求已明确）与需求分析（专注问题域，忽略开发者/运维需求），并指出架构定义架起两者之间的桥梁，需要理解更广泛人群的需求并在约束下权衡，直接支持卡片结论。
- 原始内容："设计是一种专注于解决方案领域的活动，它主要针对一组人群——开发者……需求分析是专注于问题领域的活动，它（以最纯粹的方式）忽略了开发者和系统管理员等人群的需求与约束，因为它会定义需要什么而不是能做到什么……架构定义架起了问题和解决方案领域之间的桥梁……它的关注点在于理解所有对架构感兴趣的人的需求，平衡这些需求，并在需要的地方确立可接受的权衡。"