jackljf的专栏

我们从架构的本质开始，分别对业务架构、产品架构、数据架构、应用架构、技术架构的设计提供了一些思路和原则。这些思路和原则在进行架构设计和画架构图的过程中提供一些指导帮助。最后我们再来思考一个问题，好的软件架构是规划还是演化出来？架构规划对架构的影响是很重大的。首先，好的架构是设计出来的。好的架构，系统的性能和质量都将很高。架构设计的质量直接影响架构后续向好的方向演化的难易程度。架构设计如同城市规划一样，缺少规划将难于演化。图 6演化是一个过程，这个过程或长或短，所以演化需要考虑系统的生命周期。

产品架构在业务架构的基础上，按照解决的业务问题域，划分出不同的功能模块，再根据功能模块间的关系，组合成子系统。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的，这就是应用架构和应用集成架构。应用架构分为两种：一种是单体式应用架构、一种是分布式应用架构。单体式应用架构就是系统只有一个应用，数据存储在一个 DB 等存储介质里面。

数据架构重要的输出是数据-实体关系图，简称 ER 图。ER 图中包含了实体（数据对象）、关系和属性 3 种基本成分。ER 图可以用来建立数据模型。如何准确的建立产品的数据模型，需要分解出业务需要什么样的数据。数据域的分解过程是站在业务架构的基础上，对业务域进行模型分析的过程。说起业务建模，大家很快会想到领域模型这个概念。这里的思路是通过领域建模来逐步提取系统的数据架构图。说到领域模型，这里采用四色原型法进行业务模型的抽象。在进行四色模型分析前，我们先了解下四色模型的一些基本概念。

系统架构的分解，先从业务域进行分解。狭义的业务域具有商业的概念，从这个概念来看，有的系统没有业务域，当如果宽泛一点来看，业务域就是问题域，问题域总是存在的。业务域的分解，首先是从系统入手，在需求初期可能你就得到的只是一句比较模糊的需求描述，这些需求可能来自于老板、运营或者用户（比如下图的场景）。直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品的所有问题域列清楚。

本文是架构设计实践五部曲系列文章的第一篇，架构与架构图。本文将对架构作深入的阐释，并教你什么时候画架构图、怎么画架构图。

在软件开发的两个范围维度：（1）解决方案域：就是通过软件建模和软件设计，去实现一个软件系统；是去定义世界，改造世界的一个过程。帮助业务领域更好的运作。（2）问题域：也就是业务领域，是基于解决方案域，认识世界，认识软件系统，实现系统中的业务并运作起来。在系统层面，我们最需要关注的范围维度是解决方案域，如何去分析解决方案域的问题（业务领域的相关问题）？首先需要利用软件建模去清晰的描述认识这个系统；那么如何清晰的描述系统呢，那就需要从不同视角，分析出不同的视角来清晰表达这个系统视图。