每过一段时间，就会有人跳出来批判 DDD，这东西到底是垃圾还是银弹？
在某某公司干活的时候，有一批人声称要用 DDD 改造老旧系统，彻底解决核心流程规模化之后，项目难以维护的问题。之前某篇文章里的这张图，就是在用 DDD
做项目重构之前的烂摊子：
大家都很聪明，聪明到最后没人知道这新需求到底该往哪里写了。架构师们聚在一起学习 DDD 精神，产出学习报告，大半年过去，终于出了一些成果，有些子项目完成了用
DDD 进行的重构，年底可以拿来在酒会上邀功了，这下我们跟上了业界业务开发的主流方法论，可喜可贺，可喜可贺啊。
年末的时候部门内匿名提问的小纸条却向架构师们发直球：“为什么用了 DDD 以后，
之前写过文章讲工程师应该怎么学习，讲的最多的就是要多读体系化的技术书籍。最近碰到一些朋友说读书读不进去，读的太慢，或者读完就忘该怎么办。
这篇文章解答一下这几个问题：
* 读书读不进去
* 如何加快阅读技术类书籍的速度
* 读过的书会忘记怎么办
读书读不进去
读技术书主要有两个目的，一是和工作内容结合寻找能够落地的方案，二是了解不太熟悉的领域的宏观大图，帮助自己建立知识体系，拓宽视野。
能直接和工作内容结合的书是最好的，如果我们在做流式计算领域，那把市面上常见的几本英文书：《stream processing with flink/spark》
和 《streaming systems》读完自然是应该的，书的内容和我们的工作密切相关，这种类型的书不太可能看不进去，如果看不进去，就看看自己的银行卡余额。
若是想拓宽视野，阅读的内容大多就和我们的日常工作脱离了，
假期就不聊技术了。
《Stop Reading The News》 是一个 150
页的小册子，假期闲来无事，把它读完了。最初买这本小书的原因是看到了这么一个故事：作者受邀去英国的卫报(The Guardian)宣传自己的书《The Art
of Thinking Clearly》，卫报的编辑表示对作者 blog
上的批判新闻的文章更感兴趣，希望他能详细讲一讲(有股鸿门宴的味道啊)。所以作者在没有准备的情况下，头铁地现场陈述了新闻的种种罪状，并尴尬地在现场没有得到任何回应。
卫报的编辑们作为新闻媒体的从业人员，想必是不会同意作者的观点的，不过他们还是很神奇的，把它的观点汇总起来发表在了网站上：news
《righting software》是 Pearson 出版社 2020 年出版的一本书，作者是 Juval
Löwy，今年国内也引进了这本书，中文名是《架构之道》。
中秋期间读完了这本书里我比较关心的部分，本文将其中的一些核心观点进行摘录。
作者首先总结自己几十年的经验(先表达一下羡慕)，提出了靠谱软件的设计方法，称为 The Method(中文译成了元方法)：
The Method = System Design + Project Design
这本书也就被分成了这两部分，System Design 和 Project
之前陶师傅推荐过这么一篇文章，Complexity has to live somewhere
[https://ferd.ca/complexity-has-to-live-somewhere.html]
，大致意思是系统的复杂度是没法凭空消失的，只能从一个地方转移到另一个地方，因为现实世界的逻辑就是那么多，边边角角的 case
就是那么多，你必须要处理，这必然会给系统引入复杂度。
尽管这些复杂度你可以转移给你的同事，或者外包给第三方系统，但复杂度是不灭的。
设计系统时，我们要注意到这一点，同时要管理好复杂度问题。
在《a philosophy of software design》这本书中，作者也提出了一个不一样的，
