架构的第一步——业务

下面我们从业务视点开始说起，也就是站在业务的角度去思考架构，这也是所有架构的必经之路，也是最重要的一条路，首先就是业务领域模型的建立，即对业务的总体分割，这是第一个步骤，下面我通过一个例子来进行一个解析，对于我们程序员来说，最熟悉的业务莫过于我们自己所在的软件行业，假设我们想做一款软件生命周期管理的软件（SLM，如bug管理，任务管理，风险管理系统等），首先我们需要问几个问题，在一个软件团队里面需要有哪些人（即角色），这些人分别需要用这个软件做哪些事情？首先我们来分析一下软件工程中的角色的分类。

我觉得在一个软件开发的过程中，至少应该有如下图中的几种角色（小项目的运行）。

 

我们就拿测试人员为例，虽然不是特别了解，但是我们要学会站在巨人的肩膀上，有人已经给我们整理好了，只要我们稍加阅读，整个软件行业的业务会就会呈现在我们面前，那就是Rup，通过对rup指导手册的阅读，我发现其实测试人员还可以往下细分。

下面我们那其中的测试员为例，看测试员需要使用这个SLM这个软件的哪些功能，我们先从测试员的一天开始说起，假设有一名测试人员叫小李，小李早上来到公司，首先打开工作的任务管理系统查看一天的任务列表，这里面提到了任务管理系统，我们可以提取其中的任务，还有这些任务应该是自动发送的，那么怎么自动发送的呢，这里我们可以提取出通知这样一个概念，然后小李下载了最新的可执行的代码块，这里有一个代码块的概念，对了，在这之前还有一个概念就是小李作为测试员，那么就应该有测试员所对应的权限，这里又可以把权限这样一个概念提取出来，然后小李开始使用工具开始了一天的测试任务，这里有一个工具的概念，由于人们对知识产权越来越重视，所以现在有好多软件都是买一份或几份然后共享给大家，所以工具的管理也是一个领域，在测试过程中，可能会使用到测试用例，以及测试代码单元，这里又有两个概念测试用例，和测试代码，而且在过程中一定会生成一些测试的日志（可能是工具自动生成），这里又能提取出测试日志的概念，对于测试出来的bug，需要提交到bug系统，这里还有一个bug的概念，最后小李在完成所有工作的时候还需要提交工作日志，这里面还有一个工作日志的概念，这里忘了说一点，还可能涉及到一些文档，所以就能够推导出一名测试员所相关的领域模型（如下图所示）。

所以我们即可推出所有角色所对应的各种领域模型，从而推出整个软件生命周期的领域模型。当然角色之间所对应的领域可能有所重叠，正是由于这种重叠，才使得软件生命周期体系是一个有机的整体，同时比如代码，日志等还可以泛华出更多的种类，我们可以把这些具有公共属性的模型看成一个整体去管理，这样也保证了整个体系的可持续性。

下一步，我们一起来探索一下业务流程，我们就先从离用户需求最近的角色说起——需求分析师，让我们思考一个问题，需求分析师都要做哪些事情呢？我们还是做这样一个假设，假设小李是一家软件公司的需求分析师，那么他拿到用户需求之后首先要对用户进行细致如微的调查，然后根据自己对用户所需的理解与剖析，对业务进行分析理解，最终能够将这些业务整合成一个系统，然后交给下一步的架构师，当然架构师分为系统架构师和数据库架构师，我们先说说系统架构师，假如你是一名系统架构师，你刚刚拿到小李的需求分析文档，你会怎么做，当然要先看需求文档了，找出问题，说的专业一点就是需求评估，说的直白一点就是哪些能做，哪些不能做，当然这个过程是有一个标准的需求评估标准，针对这个标准我这里要说几句，首先要看文档的目录结构，一般有这样几点，功能性描述，质量相关，还有结构，后面两个属于非功能性，这里面的结构主要有这样几种描述方式——函数式描述，用例式描述，故事式描述，函数式就是使用函数之间的调用关系来标识结构，用例式就是使用用例图（包括一定的用例描述，通常有使用者，前置条件，后置条件，场景等描述），故事式顾名思义，就是用故事的形式进行描述（一般用于敏捷开发srcrm，先简单说到这，以后细聊，敏捷很有意思），对需求进行评估之后，就要进行最关键的架构设计，同时还要建模并编写代码来验证自己的架构并同时提交给开发，同时也要关注开发的全过程，如果遇到问题还需要进行架构的重构，数据库架构师，首先也要对用户的需求文档进行研究，进行数据上的评估，然后进行数据库的逻辑设计，接下来要进行物理设计提高性能提交给开发，他也要对开发的过程进行关注，及时进行性能优化，针对相关的问题，在关键时刻还要进行数据库的重构，终于到了开发的手中，当然其实还有几种角色，这里面就不一一介绍了，如UI设计师，数据分析师，视觉设计师等，下面我就以一名开发人员的身份来展示一下开发工程师的工作流程，首先我拿到架构师提供的设计骨架要进行详细设计，然后进行编码，之后进行单元测试，集成工作，最后提交给测试人员进行测试，对反馈的bug进行修改，测试工程师这个角色也是必不可少的首先，测试人员从开发人员那块获得测试需求，要根据公司或者业界的质量标准来进行测试的设计，然后进行测试，像开发人员提交问题报告，最后提交给用户。整个软件的过程表面上看起来是一条道跑到黑的，但是在真是的情况下要进行迭代式的开发，就好比滚雪球，越滚越大，软件也越来越丰满，越来越稳定，风险也越来越低。根据我对上述过程的描述，有没有感觉，是不是可以将流程图画出来了？下面我们把业务流程图画出来，如下图

下面我们要对流程进行优化与再造（BPR），与业务组件化，并且构建业务全息展现图——CBM图，CBM图是用矩阵的方式来编排业务组件，这个矩阵的横向一般是业务使用者分层，纵向是业务领域主题域，不过这个是要费点时间的，通常要一到两个月的事件来将业务组件化（接下来的一段时间，我将会做一些实践工作，成果到时候我会和大家交流），最后就是业务的抽象化，这个是软件分析的最高境界了，ERP5做到了，把业务分为五个方向节点（Node）、资源（Resource）、迁移（Movement）、物品（Item）、路径（Path），不过想想确实是这样，例如bug管理模块，风险管理，这些都可以被归类为WorkItem，文档管理，代码管理等可以归类为Resource等。

最后我们说一下资产视图，也就是可重用的代码块，平台框架等部分。如代码工厂，缓存框架，UI框架等部分。

这里面还要补充一点，就是对非功能性需求的切割，非功能性需求该如何进行切割呢，非功能性需求主要有这样几点，可靠性、稳定性、性能等，我这里就不一一说明，就拿可靠性来说吧，维持一个系统可靠性，主要可以从两个方面考虑，一个是可预知，可预估的风险，另外一个就是不可预知的风险，打个比喻，在非典期间，好多人都吃板蓝根来预防自己患病，这就是对可预估的风险进行预防，再打个比喻我们去医院看病，为什么要去医院呢？这是因为我们不知道自己得了什么病，是在出现症状之后才进行的处理，下面我们想一下我们看医生的步骤，医生进行一些简单的询问后，会通知你去进行化验，然后医生针对化验结果给你开出一定的处方来治疗，系统运行也是如此，首先对于可预估的风险进行预防，如果在系统运行中遇到错误，那么首先可以对系统的运行状态进行检测——比如心跳法，然后对这些错误或者异常进行恢复，并且对有传播性的异常要进行隔离，这样我们就把软件的可靠性划分为这样几点预防，检测，修复，隔离。