书中在第九章着重讲到了两种思想：抽象和分治。事实上，这两种思想贯穿了全书。下面就试着从这两个方面，来谈一些感想。先说 "分治"" 分治 "就是把大问题拆解成小问题，然后逐个击破，最终将问题解决。就软件实现而言，其复杂度可以分成三个方面：业务复杂度、技术复杂度、组织复杂度。业务复杂度，再进行拆解，可以归因为业务流程的复杂性，以及业务概念的不统一。（1）对于业务流程的复杂性，需要进行流程梳理和分解，通过流程建模，来达成对流程的统一认知。（2）而对于概念的不统一，需要对业务领域进行归纳，并在此基础上统一语言和概念，并且在实践中根据实际情况不断迭代完善。技术复杂度，来源于规范的缺乏，及技术认知的不统一。（1）就技术规范而言，可以拆解为命名习惯、函数写法、函数抽象、建模语言、代码风格等。（2）而技术认知，涉及到对不同设计原则的充分理解、对不同涉及模式的融汇贯通、对建模方法的理解并形成相应的架构意识。组织复杂度，涉及到自己、团队、周遭。（1）关于自己，要保持好奇和良知、不断学习、磨炼思维、持续精进。（2）关于团队，要建设良好的技术氛围，让团队有的目标感，以至于形成团队特有的技术特色，构建差异化的竞争力。（3）关于周遭，需要去理解企业的战略和文化，理解不同团队的目标和工作方式，跟大家一起去合作共赢。再说" 抽象 "抽象就是" 从具体中抽离出来 "。首先，软件是对于现实的抽象。越是复杂的问题，需要考虑的因素越多，对抽象能力的要求越高。而能否给一个变量、一个函数、一个对象找到一个好的名字，是这种抽象能力的一个具体体现。取名是对事物的界定，好的名字需要直白表达出事物的本质，这需要对问题有深入理解，需要对相关的信息有充分消化。第二，设计原则是对共性经验的抽象；设计模式是对共性思维的抽象。（1）遵循前人总结的设计原则，可以设计出更易于扩展、易于维护的软件，避免再次掉进那些前人已经发现的坑。（2）而设计模式针对类似的问题，将有共性的代码结构抽象出来，以便随时调用，提高编码效率，改善编码可靠性。第三，框架是对规范的抽象。如何让大家对通用的架构达成共识，并通过遵守一些共性的规范而相互协作？软件世界的应对方式是提供一个" 框架 "：通过对通行架构的抽象，并提供相应的工具和规范约束，让软件世界中能在更大的范围内产生协同。喜欢这种基于实战经验总结而出的书。其中有自己大量的体味和感悟，但是又不拘泥细枝末节，有足够的总结和提炼。可读性很高！

结构清晰，定位精准的一本好书。看完之后很多心得和方法能立即拿来改善编码质量，提升应用架构能力，码农轻松变工匠。

本书是描述应用架构设计的，其中，有设计思想、方法论，还是实践框架 cola，是一本比较全面的讲清楚设计是什么，价值点，怎么做的书