系统架构的分解，先从业务域进行分解。狭义的业务域具有商业的概念，从这个概念来看，有的系统没有业务域，当如果宽泛一点来看，业务域就是问题域，问题域总是存在的。
业务域的分解，首先是从系统需求入手，在需求初期可能你就得到的只是一句比较模糊的需求描述，这些需求可能来自于老板、运营或者用户（比如下图的场景）。直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品的所有问题域列清楚。
列出问题域
问题域，是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能需要解决的问题放入产品框架的范围，能够帮助你的产品架构拥有更高的可拓展性，在后续具备迭代和优化空间。
这里以我做过的一个风控系统需求为例，问题域集合如下：
详细的操作步骤：
-
找到收到的需求中，跟产品形态、产品目标相关的语句，去列出“xx 的流程会是什么样”、“xx 该如何达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。
-
去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决。
-
按照层级去罗列所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。
确定产品方向
在经过问题域的罗列后，能够得到一个模糊的产品方向和功能范围。问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个能够在商业模式和用户体验能够形成闭环的产品需求。
在确定产品方向这个环节的详细操作步骤：
-
产品用户：需要明确产品定位的用户，解决核心用户的核心需求。
-
核心目标：思考清楚自己产品的核心目标是什么。如果以一个 KPI 指标衡量产品的价值，那这个 KPI 应该是什么。
-
依赖系统：自己的系统需要与哪些外部系统存在交互和关联关系，我们的系统在这个大的生态下，是什么定位。
以风控系统需求为例，产品方向的描述如下：
绘制业务流程
业务流程是业务架构中比较常见的图，这一步需要根据产品需求和问题域，按照业务域的流程进行绘制。
业务功能矩阵
通过对业务流程进行分析，根据功能职责，进行垂直分解，识别出业务功能和业务服务，将他们归类到相应的流程节点中去。将业务流程和业务功能点组合成一张业务功能矩阵。这张矩阵图是业务架构中为后续的数据架构、产品架构、技术架构作为重要的输入。
功能架构分层
产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。以业务架构的业务功能矩阵图作为输入，将流程图转换成按节点进行分层，节点的功能点存放在同一层中。
在此基础上将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
明确功能边界
一个具备前后台关系的产品架构图至少分三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到哪里去）。
在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。
处理不同信息层级的边界
架构图的层级表达其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。其中用户感知层和数据层通常化简为以（用户端的功能表达往往逻辑简单、数据来源问题则不是自己产品的核心功能），而功能模块则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。
处理同一层级内子模块的边界
各层次之间虽有相关，但同一层次内的子模块之间一定是相互独立、界限分明的。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。
明确系统间边界
产品边界对于开发设计系统架构、业务间的合作模式都非常重要。在架构图中用不同颜色标识清楚，各个部分所属系统的边界。通常属于自己团队的部分用亮色标识。像外部系统，如数据层的用暗色标识。
加入信息流
产品架构图在表达产品的核心功能外，也应该体现信息流动的路径。当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。
如果当前产品的主要使用角色只有一个，则只需要用箭头表明模块间信息流动的方式即可。如果当前产品涉及的角色比较多，则需要用不用颜色的线条将他们和各个模块之间的信息交互关系表示出来。
最终一种好的产品架构图，应该具备以下特点：
-
清晰的模块功能边界
-
功能经过抽象，做到标准化、互相独立
-
上下游产品功能边界清晰，架构分层明确合理，具备迭代优化的能力
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
