读书笔记@一线架构师指南

整体这本书很实际，十年前写的也不过时。今天所谓好书越来越没水平，跟时下浮夸之风气相关吧。

 

关于分阶段，每个阶段在多视图。我觉得做一件事情是要以时间轴来看。更广泛一点，应该是主题来看。一个主题，我们可以有多种视角。拿时间来说，我们确实会分步骤去做长期的实施计划。

 

关于二维需求矩阵。一个维度是功能质量约束，没啥问题。但另外一个维度是说组织、用户和开发，这里问题比较大，因为从理论上来说，我们应该考虑涉众及其利益，包括boss、客户、用户等。研发是一个过程，他却把里面的很多点都放进去了，涉及软件工程。维度不怎么合理、差一点理论。我觉得他把组织和用户分开适合面向互联网to c的场景。好比一端是商户的需求，一端是用户的需求。目标和涉众，应该是更科学的划分。

 

关于鲁棒图。他弥补了从用例到交互图之间的缺失。交互图非常的复杂，因为它会有很多场景，是一个非常重的图，我不建议用在常规的设计里面，除非是一些核心的交互场景，而且是那些不易经常发生变化的。鲁班图可以识别出来对象和过程，相当于把用例更细化掉。后面可以做做推广实践。他定性成系统的初步设计，没啥问题。

 

关于用例架构驱动还是概念架构驱动。此文说，概念架构的驱动力，等于功能、质量、约束。但实际从软件的根本目标来讲，都服务于用户和商业价值。软件本身也可是一种商业，但这比较特殊。所以核心用例驱动，这句话没啥毛病，他虽然不是一个很全的覆盖面，但是他把软件的本质体现出来了。

如果求全我们可以说，是需功能需求和非功能需求驱动。但本质并不对，很有可能很多功能需求，很是很傻逼的产品经理提出来的，并不代表着市场的认可。需求是伪需求，那根据伪需求构建的系统也是伪系统，所以，真正是市场驱动着软件的一个架构。

 

关于概念架构和方案的区别。概念架构他关注抽象的部分，它没有接口约定和子系统间的交互。方案更偏内容层面。

 

关于逻辑架构的分层、分区和机制。主要关于机制，他的定义是为了完成某一目标、基于抽象角色的协作方式和流程。可以理解为是基于角色和USECASE的功能流程。有两个关键词，一个是角色，另外一个是流程。