一线架构师实践指南 摘录
需求进，架构出。
ADMEMS Architectural Design Method has been Extended to Method System 架构设计方法已经扩展到方法体系。
三个阶段：
预备架构 Pre-acrhitecture阶段，简称PA阶段。全面理解需求，从而把握需求特点，进而确定架构设计驱动力。
概念架构 Conceptual Architecture阶段，简称CA阶段
细化架构 Refined Architecture阶段，RA
软件架构师不必是需求捕获专家，也不必是编写〈软件需求规格说明书〉的专家；但他一定应在需求分类、需求折衷和需求变更的研究方面是专家，否则他和优秀软件架构师相比就输在了“起跑线”上。
需求 = 功能 + 质量 + 约束。
用例是功能需求的实际标准。
用例涉及、但不涵盖非功能需求。
关键需求决定架构，其余需求验证架构。
Requirements management 需求管理
Requirements activities:InvestigationFeasibilityDesignConstruction and testRelease
需求入门： 软件需求的三个层次
发现做正确的事比正确的做事更重要。
业务需求
描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。
用户需求
用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值 ，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。用例、用户故事、特性等都是表达用户需求的有效途径。
功能需求
系统分析员描述 开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。 这些需求记录在软件需求规格说明（Software Requirments Specification）中。
问题是方法之父。
Pre-architecture阶段：ADMEMS矩阵方法
约束是架构设计的上下文。
确定关键功能的4条规则：1. 核心功能2. 必做功能3. 高风险功能4. 独特功能（覆盖了上述3类功能没有涉及的职责）
不同系统的架构，为什么不同？
答：需求不同，所以架构不同；当然，“需求”不是单指“功能需求”，而包含了功能、质量、约束等方面。
架构设计中，应何时确立架构大方向的不同？
答：进行概念架构设计时应确立架构大方向。架构设计贵在有针对性，概念架构针对重大需求、特色需求、高风险需求的要求，给出高层次的解决方案--这就是概念架构最重要的意义。
阶段是先后关系，视图是并列关系，这其中有本质区别。
Overview of a three-tier application vectorVersion
细化架构和概念架构之间存在如下典型差异：接口：在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义（只有抽象的组件和抽象的交互机制）子系统交互机制：细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；
第13章 逻辑架构
基于3层架构进行"分层细化"的一种方式。
本书为"机制"下的定义是：软件系统中的机制，是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式。机制不仅包含了协作关系，同时也包含了协作流程。
基于接口（和抽象类）的协作是机制，基于具体类的协作则算不上机制。
13.5 贯穿案例
