业务架构/解决方案架构

核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构。

业务架构就是在业务需求初期，将模糊的需求描述转变成清晰的问题域，梳理出清晰的业务流程，为产品架构提供输入。问题域是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围。能够帮助我们的产品拥有更高的可拓展性，在后续具备迭代和优化的空间。在经过问题域的罗列后，我们应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。根据核心需求和问题域的答案，梳理出业务流程。

业务架构包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须设计软件架构。试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重建，更不要说直接拿别人的现成架构方案了。

例如，A 业务中有套 A 系统，恰巧 B 业务需要解决类似 A 业务的场景。此时很多情况，B 业务的人员会考虑把 A 系统直接拿过来，以为做一些简单的修改，就能在 B 业务中落地。结果在系统落地的过程中，很多功能模块不能直接使用，都要重新按照业务进行修改。最终的结果是，A 系统经过不断的重写修改变成了 B 系统。上述的案例正是由于业务架构没有做到位，没有做好软件架构的分析和设计，所以我们很难看出两个系统有多少差别，也无法确定用一个业务系统去覆盖另一个业务系统的可行性有多大。相反，对 A 和 B 业务领域进行业务架构梳理，我们就能清楚发现两者的一致与区别，就能有效的评估系统覆盖的可行性和合理性。

经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。

应用架构

根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。应用架构自顶向下又会分别着眼于产品的功能模块划分、应用系统的划分以及不同功能模块、子系统所需要的技术选择。

功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。从产品的角度来看，应用架构就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了应用架构的功能分层。

应用系统的划分着眼于实现我们的功能模块应该分哪些应用系统，应用系统间是如何集成的。在业务架构的基础上，按照解决的业务问题域，划分出不同的功能模块，再根据功能模块间的关系，组合成子系统。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。

应用的技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对于的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。

数据架构

专注于构建数据中台，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。

企业架构由业务架构驱动，从业务架构分析业务流程、定义数据架构，流程和数据结合定义产品架构。这中间，数据架构起着至关重要的作用。企业 IT 系统的价值并不在于选取的技术有多先进，使用的硬件有多强大。而是企业业务数据的处理和存储。一家公司最宝贵的资产无疑就是数据。毫无疑问，在当今大数据的时代背景下，缺少数据资产的建设和使用，就失去与同行业争夺竞争的机会。

数据架构主要解决三个问题：

• 系统需要什么样的数据：数据是对客观事物的真实表现，企业业务过程中的所有对象的状况都可以用数据记录下来。业务运营过程中有两条重要的线索：流程和数据。业务流程离不开数据流转，业务运营状况通过数据反映。基于业务架构的端到端的流程建模过程中，会衍生出对应的业务数据对象，需要与数据架构模型对接。流程模型和数据模型对接后落实到应用层面，就形成了产品架构。数据架构中的数据包含静态数据和动态数据。相对静态部分如元数据、业务对象数据模型、主数据、共享数据。相对动态部分如数据流转、ETL、数据全生命周期管控治理。

• 如何存储这些数据：数据架构是为了建立一个共享、通用、一致的数据基础平台，解决企业信息孤岛。如何存储业务数据，需要结合自身需求，采取合适的数据分布策略。通常，数据存储的分布策略有两种：一种是集中式存储，一种是分布式存储。集中式存储就是讲数据集中存放于总部数据中心，所有的下属机构或子公司不放置和维护数据，都想总部数据中心进行访问。分布式存储就是数据分布存放于总部、分支机构或者子公司，每个分布节点需要维护和管理自己的数据。分布式的数据存储架构中，还需要考虑每个分布式节点的数据与总部节点数据进行同步、备份，做到数据资产的安全、可靠。

• 如何进行数据架构设计：数据源自于企业的业务流程，从业务流程中我们可以找出领域对象，基于领域对象进行分析，就能得到对象的属性。根据业务关系进而抽取领取对象之间的关系。因此，领域建模是一种对数据架构很有帮助的建模思想。通过领域建模，我们不仅能清晰的反映企业的业务域，还能清晰的描绘出一幅企业的数据模型。数据模型最常用的视图就是 ER 图，它主要描述企业数据实体、属性和关系。

中间件架构

专注于中间件系统的构建，需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP 之间进行权衡。

运维架构

负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

物理架构

物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。