这书名起的，我都不太想往这写。大概翻了一下，整本书很「散」，大的章节顺序还有迹可循，小的章节较凌乱。
前言
格局不是只有三室两厅而已
不要执着于追求传统格局的配置，你家才有机会复核自己的需求
通风采光比风格重要
第 1 章 – 装修前
设计师 ~ 施工队
- 你对工法的认识够不够格来监工
- 你有没有时间监工
- 你的个性够不够果断
按这几条来看，我找设计师吧。但是我对设计师和施工队的概念理解，好像和作者不一样，不知道真正的装修市场中，书中的「设计师」和「施工队」是指什么角色。
挑出适合自己家的照片
我们喜欢的，不代表别人懂
挑照片 4 大原则
- 为了可实现，格局要挑与家里差不多的
- 为了省钱，挑木工少的
- 为了好看，挑地板颜色跟你家一样的
- 为了预算，挑装修与家具费用在你能力范围内的
收纳大搜查
记录家当
让收纳设计迁就我们，以自己的习惯出发。
不是做「木柜」才叫收纳设计。
找个空间当储藏室。
学会做决定与负责
别把决定权交给设计师
只要使你决定的事，就不能反悔，或者说可反悔，但要付钱重改格局。
学会听建议，下决定，然后负责。
装修流程可分为两大部分，一是前期作业，一是施工工程。前期作业想得越详细越好，日后重做或追加的施工项目会减少很多，也就越省钱。
- 前期作业
- 拆除
- 水电
- 瓦工
- 木工
- 油漆
- 粗略清洁
- 设备进场
- 仔细清洁
- 家具窗帘进场
由于放假和疫情，很久没有往这里写书摘了，今天重新开始。
返程回家，出了高铁打了辆滴滴，有一段路上了高速。下高速时量了体温，问了从哪来到哪去。进小区门之前，又量一次体温，又记录了一次从哪来到哪去。
物业第二天又来在门上贴了个要「居家隔离」的纸，并且让签了一个保证老实在家待着的承诺书。
又过了一天，辖区防疫站又打电话来核实一下从哪里来的。
小区里出现一例（有可能不止一人，而是一家人）新型冠状病毒肺炎病例。在家自我隔离再待两个星期吧。
第 34 章 – 拾遗
代码设计和代码结构的几种方式：
- 按层封装，也就是传统的水平分层架构
- 按功能封装，即垂直切分，根据相关的功能、业务概念或者聚合根来切分
- 端口和适配器，参考
- 按组件封装
前两种方式不够好，端口和适配器的方式是之前章节介绍的架构，按组件封装是本章的作者提出的新的方式。
架构图中依赖方向没有问题，但是有可能会出现 Controller 绕过 Service，直接用 Repository 的现象（宽松的分层架构），这是不合理的。
对「组件」的定义：在一个执行环境（应用程序）中的、一个干净、良好的接口背后的一系列相关功能的集合。
按组件封装，如果写了「绕过」的代码，在编译阶段就会被阻止，因为 Repository 不暴露在外。
利用编译器来维护架构设计原则，而不要依赖个人自律和编译过程之后的工具。
第 33 章 – 案例分析：视频销售网站
架构设计要遵守依赖关系原则。所有跨越边界的依赖关系都应该是同一个方向，而且都指向包含更高级策略的组件。
两个维度的隔离：1，根据单一职责原则对所使用的系统的各个角色进行隔离；2，对依赖关系原则的应用。这两个维度的隔离都是为了将不同变更原因和不同变更速率的组件分隔开来。
第 32 章 – 应用程序框架是实现细节
框架并不等同于系统架构——尽管有些框架确实以此为目标。
应用程序与框架强耦合至少有以下几项风险：
- 框架自身的架构设计很多时候并不是特别正确的。
- 框架可能会帮助我们实现一些应用程序的早期功能，但随着产品的成熟，功能要求很可能超出框架所能提供的范围。
- 框架本身可能朝着我们不需要的方向演进。
- 未来我们可能会想要切换到一个更新、更好的框架上。
我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它们进入内圈。
不要让框架污染我们的核心代码，应该依据依赖关系原则，将它们当作核心代码的插件来管理。
第 31 章 – Web 是实现细节
GUI 只是一个实现细节。而 Web 则是 GUI 的一种，所以也是一个实现细节。
第 30 章 – 数据库只是实现细节
数据库并不是数据模型。数据库只是一款软件，是用来存取数据的工具。一个优秀的架构师是不会让实现细节污染整个系统架构的。
关系型数据库系统是为了优化磁盘存储而设计的。
数据库终究只是在硬盘和内存之间相互传输数据的一种手段而已。从系统架构的视角来看，真的不应该关心数据在旋转的磁盘表面上以什么样的格式存在。实际上，系统架构应该对磁盘本身的存在完全不关心。
数据本身很重要，但数据库系统仅仅是一个实现细节。