读《领域驱动设计》
领域是由业务上知识和需求构成的，领域驱动设计就是在强调模型要反应领域知识，而设计实现要与模型密切关联，相辅相成。
我对业务建模的态度与书中上述观点有些相似之处，不过我之前只有一些模糊的认识：一、设计与业务现实背离肯定是有害的。二、如果在努力之后，模型还是不能贴合现实世界，那一定是对现实世界的认识还不够深刻。
第二点确实还停留在一个浅层的定论上，而按书中所言，模型不能反应领域的时候，一方面是需要继续学习领域知识，这里又可以分成直接学习相关知识或间接学习别人的建模方式；一方面也可以在模型内部寻找突破，比如挖掘遗漏的概念、分析现有模型矛盾之处等。
这只是本书带来的深层认知的一个小的点。
书里还有一些让人顿悟的亮点，比如：
- 图不是越详细越好，如果想在图中展现出所有的细节，那么图就会沦为另一份代码。
- 语言有魔力。人类的自然语言本身就包含了高度的抽象能力。开发人员之间的日常交流中蕴含着遗漏的概念、突破的契机。而当一个抽象概念的恰当名字诞生时，整个开发组、架构组以及业务方都会低语它，并将其纳入 Ubiquitous Language 当中。
- 我原以为“封装变化”已经很高级了，但往上还有“封装认知”这一说法。屏蔽变化只是减少认知负载的一种。让接口表现其意图，让人没有心理负担地去使用，这样的封装确实更值得实现。
- 代码的复用是好的，但模型的复用更值得追求。（“分析模式”可以说是大份的泡面里的脱水蔬菜了）
- 类之间的关系有“低耦合，高内聚”的说法，这其实是概念上的关系，在设计上的，冰山露出水面的一角。
- 没有参与过开发的架构师提出的模型或建议可以忽略。模型之于设计，架构师之于开发组。模型与设计上的相辅相成，离不开架构与开发的密切反馈。
本书阐述的观点、模式，是比平常的面向对象设计更高一层的设计理念、元素。面向对象的设计关注得更多的是类本身的职责以及类与类之间的关系。在一个大型的系统中，过于关注具体的类，容易陷入“只见树木，不见森林”的陷阱中。所以大型系统中需要关注的是更大尺度上的结构，也就是书中最后一部分“战略设计”中才提到的 Bounded Context 以及“大型结构”（模型的设计模式）。
这一部分十分重要，但也是书中限于篇幅无法详尽阐述的，具体而言就是论证和结论固然是好的，但举的例子无法起到表达观点的作用。毕竟尺度拉大了，微观之处就会失去聚焦。例子中虽然有结构上的叙述，但没法让人看到形成这种结构的原因——即省略的细节。
书中还给读者描绘了一幅程序员梦寐以求的理想图卷：经过精炼和重构之后，项目获得了突破，深层模型与柔性设计浮出水面。深层模型中各种概念构成了一种语言，通过简洁的组合就可以准确地描述业务。同时柔性设计使得代码易于理解，方便修改甚至是重构。
说实话，这样的程序太美好了，说不定每一个不写垃圾代码的程序员升入天堂后会有72个这样的项目供其开发维护（🌿，死了还要写代码，这是天堂还是地狱）。这样的代码是值得追求的，不论是追求的过程还是最后达成的效果，都是一次洗礼，让人有一种明心见性的感悟（我没经历过，我猜的😅）。
好书，值得再读一遍，希望能在后续的工作中运用起来其中的原则。