第2章　逻辑架构设计

业务需求是所有架构设计的依据。

架构设计必然是从需求分析开始的，因为所有架构设计的依据都来源于业务需求。因此，在弄清需求之前，是没有办法进行架构设计的。

然而，弄清需求并不意味着“客户说什么，我们就做什么”，需要有一个分析设计的过程。我们首先应当找出用户的原始需求，理解它们背后的动机，也就是那些业务痛点。然后，再思考运用什么样的技术，以什么样的方案去解决问题，确定系统最终为用户提供什么样的功能。这个过程就是“逻辑架构设计”。也就是说，逻辑架构的输入是用户需求，但最终输出的是“我们的系统到底为用户提供什么样的功能”。只有确定下来这些功能，后续才能顺利地开展架构设计的其他工作。

但是，一个复杂的业务系统，有那么多的功能要实现，应该怎么进行逻辑架构的分析呢？我们的思路是“粗→细→粗”。前面提到，要成为合格的架构师，首先应当培养架构师的思维习惯，也就是遇到问题首先应当从整体、从大局、从宏观的角度去思考，这样的思路同样体现到了逻辑架构设计的过程中。所以，当我们刚接手一个项目，拿到用户需求文档，而用户需求文档有那么一大摞时，应当先看什么呢？是去仔细查看每一个功能吗？不！如果我们这样做了，就落到细节中，就不能看清全局了。我们首先应当查看的是目录。用户在编写需求文档时，会通过章节划分功能模块。同时，通过功能模块中每个功能的命名，可以大致猜测每个功能的内容。这样，通过阅读目录，我们对整个系统就有了一个整体的、直观的认识，在这样的认识的基础上再逐步细化，逻辑架构的工作就可以逐步开展起来了。

另外一个非常重要，但特别容易被大家忽略的，就是用户需求文档的概述部分，特别是客户在概述部分的建设目标。众所周知，客户在提需求时都“要的功能多，给的时间少”。要做那么多功能，却只给那么点儿时间，就使得开发团队只能加班加点工作，其质量得不到保证。这种状况会给项目带来巨大的风险，必须要采取措施规避这个风险。如何规避这个风险呢？思路就是，通过概述了解客户的建设目标，然后根据建设目标为每个功能设定优先级。注意，这里一定不能让客户去设定优先级，让客户去设定优先级就只能得到一个结果，那就是所有的功能都优先。因此，要通过对业务的理解，对客户建设目标的理解，然后将客户最急切要使用的功能，优先制订开发计划做出来，优先交付给客户使用。当客户使用上这些功能以后就没有那么着急了，我们就可以在后面的开发计划中逐步交付，满足客户其他的需求。因此，我们可以将项目分为一期、二期、三期，逐步开发、逐步交付，从而有条不紊地开展研发工作，风险也就得到了规避。

在前面整体认识的基础上，接着要将需求逐步地细化。整个系统分为哪几个子系统或功能模块？这些子系统或功能模块又包含哪些功能？每个功能都有什么流程和哪些分支？以什么样的界面与用户交互？最后这些业务包含哪些业务实体与外部接口？所有这些问题都是在逻辑架构中逐步细化的。

以上这些工作的工作量极其大，它们都是由架构师一个人独立完成的吗？这也是许多同学的疑问，也就是说，整个架构设计是架构师一个人独立完成的吗？实际上并不是，而是在架构师的指导下，由各个团队成员共同完成的。因此，逻辑架构的设计是在架构师的指导下，由需求分析人员与架构师一起完成的。架构师在这里面更多的是起到带领与指导方向的作用。

团队完成了对业务的梳理之后，我们对整个系统就有了完整而清晰的认识，那么此时逻辑架构的分析工作是不是就可以结束了呢？也不是的，这里还要有一个由细到粗、总结归纳的过程。也就是说，前面的所有分析都是源于用户需求文档，这时对模块的划分、对功能的定义，都是由客户定义的。对于软件开发来说，客户是非专业的，他们对模块的划分、对功能的定义不够专业。因此，当我们对整个系统有了完整而清晰的认识以后，就需要重新去思考以下问题：客户对模块的划分对吗？有的模块是不是需要拆分？客户对功能的定义对吗？有些功能是不是需要合并？通过这些分析，我们最终做出来的软件会更加专业，设计会更加合理。