架构与设计 - 架构图参考 - 《Architect - 架构师之路》

架构分类
业务架构：
- 参考1
- 参考2
应用架构：
技术架构：
参考文档

架构分类

架构大致可以分为4类：业务架构、应用架构、数据架构和技术架构，整体逻辑关系如下：

整体关系如下：

业务架构：

解释1: 使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分。所以熟悉业务是关键。
比如做一个团购网站，你需要把商品类目、商品、订单、订单服务、支付、退款等进行清晰划分，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。
解释2：建模分析的主要阶段，关注流程和模型的可复用、可扩展，领域边界划分；产出物如业务流程、领域模型、功能逻辑架构。
解释3：也叫解决方案架构. 核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构

参考1

参考2

应用架构：

解释1：它是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。
解释2：系统划分、系统间的关系；产出物如分层架构、系统拓扑架构等
解释3：根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）

参考1

例如，下图就将系统分为数据层、服务层、通讯层、展现层，并细分写明每个层次的应用服务

参考2

参考3

参考4(按领域划分应用)

上图为财务中台系统内应用架构图，采用分层架构模式，图里的应用层、领域层、基础设施层和DDD中的概念一致，但它们是容器层次下的分层逻辑，视角是整个系统内

参考4

技术架构：

解释1：系统的技术实现，含开发架构、物理部署架构、高并发、高性能、高可⽤、可扩展等。
解释2：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构则是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。
技术架构解决的问题包括：纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。