今天阅读了《一线架构师指南》的6-10章，对在阅读过程中的心得进行总结。
第六章先是讲述了两个架构师的故事，从案例出发对架构进行掊击和讲解。首先是小张的故事，他新接手了一个项目，需要他对项目进行设计，但是经验不足，于是他在网上搜索相关的信息，主要是认识到了接口的重要性，而且认识到“架构=组件+交互”，然后是老王，即将和客户见面的他看着公司设计的PPT认为对客户没有说服力，两人都在准备方案，小张主要是进行概念架构的设计，老王主要是明确价值观，小张进行重大需求塑造概念架构，归纳了“5大因素”老王进行概念架构体现重大需求，进行了分层设计，不仅满足了用户的需求，而且最终的结果也很理想，两人都进行了总结，小张认识到了概念是设计大系统的关键，老王认识到了概念架构是售前必修课。
第七章介绍的是概念架构，首先是概念架构的定义：概念性架构界定系统的高层组件，以及他们之间的关系，概念性架构意在对系统进行适当分解，而不陷入细节，借此，可与与管理人员，市场人员，用户等非技术人员交流架构，概念性架构规定了每个组件的非正式规的架构图，但不涉及接口细节，其实际意义就是面对两个问题：不同系统的，为什么不同，答案是：需求不同，所以架构不同，当然，“需求”不是单指“功能需求”，而是包含了功能，质量，约束等方面。第二个问题：架构设计中，应何时确立架构大方向的不同，答案是：进行概念架构设计时应确立机构的大方向，架构设计贵在有针对性，概念架构针对重大需求，特色需求，高风险需求的要求，给出高层次的解决方案，这就是概念架构最重要的意义。之后有对业界现状进行了分析，分析了误将“概念架构”等同于“理想架构”，误把“阶段”当成“视图”，并对其进行了分析解释。然后是概念架构阶段的三个步骤：初步设计，高层分割，考虑非功能需求，并对这三个方面进行了解释。
第八章讲述了初步设计，首先是介绍了初步设计对复杂系统的意义，但也指出初步设计不是必须的，架构师只有在设计复杂系统时才需要它，初步设计的目标是发现职责，然后介绍了这一步的辅助工具：鲁棒图，鲁棒图包括三种元素：便捷对象，控制对象，并将其与MVC进行了类比，然后介绍了鲁棒图的一些其他的知识，比如为什么鲁棒图叫鲁棒图，系统的鲁棒性也经常被翻译为健壮性，并且同时和容错性含义相同，鲁棒图的作用除了初步设计之外还能检查用例规约是否正确和完善。在这本书中，鲁棒图最重要的一点就是：它是初步设计技术，对其进行分析并给出：需求分析不等于系统分析，系统分析不等于初步设计，然后提出了基于鲁棒图进行初步设计的10条经验：
遵守建模规则
简化建模语法
遵循3种元素的发现思路，
增量建模
实体对象不等于持久化对象
只对关键功能（用例）画鲁棒图
每个鲁棒图有2~5个控制对象
勿关注细节
勿过分关注UI，除非辅助或验证UI设计
鲁棒图不等于用例规约的可视化
然后有建模规则：
参与者只能与边界对象交谈
边界对象只能与控制对象和参与者交谈
实体对象也能与控制者交谈
控制对象既能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈
之后又从案例入手进行刨析，这就不细说了。
第九章讲的是高层分割，这里一般有两种实践套路：切系统为系统，切系统为子系统。
对于切系统为系统，从缩略的说法来讲，具体是指：系统比较复杂，须要进行两层高级划分，首先，把系统切成更小一级的系统，每个更小一级的系统都可以有单独的需求，设计，实现等，之后，针对每个“更小一级的系统”，进行“切系统为子系统”，然后是切系统为子系统，这一步常见的方式就是分层。分层式概念架构设计作者将其总结为3+1种流派：
Layer逻辑层，Tier物理层，按通用性分层，技术堆叠，通过案例进行讲解，然后有对一线架构师的提醒：高层分割很重要，但不是概念架构的全部，除了切分决策之外，概念架构还包括技术选择，权衡策略等种类的决策，例如为了支持各种相互矛盾的非功能需求，仅调整切分方式是远远不够的。
第十章讲的是考虑非功能的需求，并介绍到非功能需求往往非常笼统，而场景是一种明确性很强的技术，目标-场景-决策表可以让架构师理性地应对非功能需求。