业务分析与设计的方法

如今，用户的需求越来越复杂，变化越来越快。如果我们仍然通过需求管理、需求跟踪等管理方法来限制和减少频繁变化的需求对软件开发的影响，软件开发过程会变得僵硬，程序员会更加疲劳。

此外，用户的需求通常来自某个专业领域，如法律、金融或电子商务等，每个具体的需求都有其特殊的复杂性，因此几乎没有人能够第一时间掌握这些专业领域的需求本质。所以经过几次进化，用户的需求变得认不出来，每个“加工制造环节”都认为自己在做“正确的事情”。在实际工作中，这种情况一再上演。例如，当产品经理宣讲产品需求文档(PRD)时，他需要用流行的业务语言向业务人员“翻译”专业术语，还需要用技术语言向开发人员“翻译”。这很容易导致各方获取的信息不平等，业务人员和技术人员的理解可能不一致。

因此，聪明的工程师引入了灵活的OOAD方法。面向对象的分析和设计方法对复杂需求的解决方案是让建模专家对需求进行分析，建立需求之间的关系。

注：面向对象的分析与设计分为系统分析和系统设计两部分。还有“系统分析师”和“系统设计师”两个职称。这种拆分的结果是需求分析的结果无法直接进行设计和编程，但是可以运行的代码与需求不匹配，导致客户在运行软件后发现很多功能不是自己想要的，软件无法快速跟上需求的变化。

虽然面向对象的分析和设计思想给分析和设计带来了极大的灵活性，也对软件开发产生了前所未有的影响，但它也有一定的局限性：面向对象的分析和设计主要集中在微观层次的抽象上，比如类和对象实例；通常需要为每个问题领域创建一个单独的用例分析模型。在很多情况下，项目或产品的大方向变得模糊，很难全局控制系统的总体目标。因此，这种系统分析和设计方法具有很大的风险。

面向对象分析与设计的局限性催生了面向服务的分析与设计(SOAD)方法，有效地弥补了面向对象分析与设计的局限性。与此同时，面向服务架构(SOA)也进入了大众的视野，迅速流行起来。

面向服务的分析和设计不是一种全新的分析和设计方式，而是从不同抽象角度设计的商业模式。面向对象的分析和设计可以说是一种自下而上的设计方法。虽然面向对象的方法相比面向过程的方法有了很大的改进，但是面对复杂的市场需求，面向对象的分析和设计捉襟见肘。这时需要从更高的层面分解市场需求，面向服务的分析设计应运而生。在进行面向服务的分析和设计时，将采用自顶向下的设计方法。首先，业务流程和服务应该分开，然后对象应该细化。面向对象分析与设计和面向服务分析与设计之间的抽象关系如图3.16所示。

图3.16

那么，面向服务的分析和设计是最好的吗？它的局限性是什么？

众所周知，软件开发的过程通常包括需求、分析、设计、开发、测试和交付。无论是面向对象的分析与设计，还是面向服务的分析与设计，系统分析与设计都是分离和拆分的，即分析人员从领域中收集基本的业务概念，系统设计人员将基本的业务概念映射到相应编程工具的构建组件中。在这个过程中，由于分析模型和设计模型的不同，在分析和设计之间形成了一个鸿沟，如图3.17所示。

图3.17

2004年，著名建模专家埃里克埃文斯发表了他最具影响力的名著《领域驱动——设计架构》。

注意：DevOps 的出现又进一步填平了开发和部署之间的鸿沟，值得注意的是，任何新技术或概念都不是人们凭空想象出来的，都是为了解决人们在生活和工作中遇到的问题。架构师也需要具备发现系统中的问题并给出相应解决方案的能力。

系统分析与设计的三个发展阶段

下面讲讲系统分析与设计的三个发展阶段。

面向数据驱动分析与设计

面向数据驱动分析与设计可以说是系统分析与设计的第一阶段。

软件设计总是从设计数据库及其字段开始的，这一阶段的特征就是围绕数据库编程，应用系统是典型的两层架构，分为展示层和数据库层。该阶段的典型技术为Delphi和VB等，如图3.18所示。

图3.18

这种面向数据驱动分析与设计的方法导致了过程化的编程思维，因为数据库结构由DBA设计后交由程序员编写大量的SQL语句实现，而SQL语句执行是有先后顺序的，所以程序员大多形成了面向过程的思维方式，长此以往形成了习惯就难以改变。

面向过程（Procedure Oriented）是一种思维方式，在面对一个问题时，我们通常先关注解决这个问题的步骤，即过程。比如对于如何将大象装入冰箱这个问题，我们想到的步骤是：第1步，打开冰箱；第2步，装入大象；第3步，关上冰箱。这就是典型的面向过程的思维方式，虽然这样可以更加直接、有效地解决问题，但是面对更复杂的问题时，解决问题的过程会变得非常复杂和难以理解。

同样，面向数据驱动分析与设计有以下明显缺点。

◎ 不能迅速、有效、全面地认识和反映需求，在这种分析与设计思维中，世界不仅由简单的关系数据组成，还使用关系数据库反映现实需求，这不符合人类的自然思维，是一种扭曲的分析方法。

◎ 系统的性能很难提升，容易导致软件运行时的负载集中在数据库端，使系统变成集中式和高风险的大型单体模式（Monolithic），丧失分布式集群处理能力。

◎ 面向对象的编程语言和关系型数据库本身是矛盾的，因为关系型数据库分析与设计本身是面向过程的（这一矛盾在当今的实现中依然存在，不过在领域驱动设计中已有解决方案）。

面向对象和服务分析与设计

随着系统的复杂度越来越高，面向数据驱动分析与设计所存在问题也越来越明显，因此产生了具有划时代意义的面向对象和服务分析与设计的方法，应用系统也变成了经典的三层架构：展示层、业务逻辑层和数据访问层，如图3.19所示。

图3.19

此时出现独立进行分析与设计的两个阶段，系统分析与设计开始上升到一个更高的层次，拥有自己的一套科学且艺术的方法论，但也带来了一个致命的缺点：分析阶段和设计阶段不能很好地衔接，出现了难以逾越的鸿沟，因为分析人员负责从需求领域中收集基本概念，而设计人员负责指明一组能在项目中适应编程工具构造的组件，这些组件必须能够在目标环境下有效执行，并能够正确解决应用程序出现的问题。

可以看到，分析阶段和设计阶段的目标并不一致：分析人员只关注需求分析，并不关注是否适合设计或者能否导出适合设计的分析结果；设计人员发现分析结果过于简单，无法进行编码实现。于是，分析阶段和设计阶段无法对接，导致整个项目无法顺利进行，以失败告终。

另外，在分析阶段和设计阶段虽然都使用了UML，但是UML不是思想方法，只是一种分析与设计工具。假若将UML类比为CAD绘图软件，那么会CAD的绘图员就是建筑师吗？显然不是。所以，UML不是银弹，更不等价于分析与设计方法。

面向问题域分析与设计

问题域模型有一个流行的名字：领域模型，是对现实世界或领域中的对象的可视化表示，可分为概念模型、领域对象模型和分析对象模型。

Eric Evans 在 2004 年 发 表 了 Domain-Driven Design-TacklingComplexity in the Heart of Software的论文，主题便是领域驱动设计，还提出领域模型的分层架构，将整个系统划分为基础设施层、领域层、应用层和用户接口层，如图3.20所示。

图3.20

领域建模是一种艺术，融合了分析阶段和设计阶段，目的是使复杂的软件快速应付变化。领域模型同时适用于分析原型和程序设计，如果一个模型在实现时不具备可行性，就需要重新寻找新的模型，如果该模型没有忠实表达领域的关键概念，则也必须重新寻找新的模型。所以，领域建模的过程把分析阶段和设计阶段变成了单个循环阶段，把分析与设计紧密联系起来，使领域建模专家不再只关注需求概念的收集，也关注程序代码的设计与实现。3.5～3.7节将介绍面向对象分析与设计、面向服务分析与设计和领域驱动设计的详细用法。