这篇文章深入探讨了不同的架构领域，例如 DevOps 和数据架构，它们如何互连，以及它们在整体解决方案架构中的重要性。
在我为一家全球咨询公司担任金融服务解决方案架构师期间，我经常质疑实践企业架构的最佳方式。许多架构顾问面临的一个共同挑战是大多数客户公司坚持使用他们专有的企业架构内容。我观察到，经常这样的架构内容并不总是能区分解决方案和软件架构。
本文不是学术论文。在本文中，我介绍了我的经验和想法，以帮助我的同事更好地理解两个相似但不同的架构学科之间的模糊差异。至少，这篇文章可能会通过评论部分引发对话，这可能会说服我我错了。
解决方案架构
术语“解决方案架构”通常用于描述为特定架构利益相关者受众开发、记录架构内容的过程，以实现特定的业务或组织成果。
解决方案架构将解决单个业务和组织利益相关者的需求和关注点，从而产生解决方案架构文档中捕获的相应功能和非功能需求。解决方案架构文档在相关架构领域的上下文中描述目标架构，例如业务、数据、应用程序、技术、集成、安全等。解决方案架构文档将目标架构详细阐述并分解为具体的架构可交付成果，也称为构建块对于每个架构域。在本文中，我将使用一个虚构的网上银行贷款应用程序的示例来按每个架构域分离此类关注点：
- 业务架构： 描述每个用户角色完成在线贷款申请的事件和操作顺序
- 数据架构：定义完成贷款申请所需的信息范围，如信息格式、来源和质量。数据架构还解决了对私有数据安全性和完整性的担忧，同时确保了性能、可用性和一致性
- 应用程序架构：将应用程序分解为细粒度的单一职责用户体验、功能、数据组件，贷款开户网络或移动应用程序包含这些组件
- 集成架构：识别外部数据和功能资源，并定义与这些资源交互的方法
- 安全架构：处理客户身份和访问管理 (CIAM) 问题，例如用户注册、身份验证和密码恢复
- 技术架构：解决基础架构对高可用性和性能的需求：
- 计算（虚拟化、容器化、无服务器）
- 网络（防火墙、子网）
- 存储（对象、块、文件共享）
- DevOps 架构：专注于通过 CI/CD 管道和应用程序可观察性（日志监控、事件管理）增强变更管理操作
解决方案架构文档捕获了上述关注点和决策，并提交给项目和架构审查委员会，以确保它满足组织标准以及项目时间和成本限制。
软件架构
一旦定义、审查和批准解决方案架构，项目现在可以过渡到称为 SDLC 阶段的构建阶段。软件架构师现在将开发软件架构作为设计跑道的一部分。软件架构的主要重点是根据已知的功能和非功能需求定义和记录软件结构和行为，并使软件工程师能够生产功能软件。这里的目标与解决方案架构的目标有很大不同，解决方案架构的目标是定义应用程序、数据、基础架构构建块和依赖项。软件架构师将应用软件架构风格和设计模式来概述实现用户体验 (UX)、功能、和解决方案架构文档中定义的数据应用程序构建块。正如我所提到的，软件架构的主要目标是实现软件工程交付。我发现最有用的软件工程图是领域对象模型类、服务组件、序列和部署图。
- 域对象模型类图 对于定义域驱动设计至关重要，以确保跨 UX、API 和后端数据层的数据结构一致。
- 服务组件图 将应用程序分解为可以实现为自包含微服务的有界上下文 REST API
- 序列图 演示了如何通过由多个服务交互组成的编排流程来实现每个用户功能
- 部署图 对于演示每个软件组件所部署的平台（例如 VM、Kubernetes pod 或无服务器 lambda）以及如何跨多可用区域配置高可用性是必要的。
我希望我已经证明了解决方案和软件架构是两个不同的学科，具有不同的目的和受众。解决方案架构师可以成为软件架构师，反之亦然吗？在我看来，是的，只要她/他知道每个学科什么时候是合适的。
最后，有兴趣想要学习相关资料的朋友点赞三连+关注后点进我的主页右上角私信（555）即可领取免费资料