jatsz：https://book.douban.com/annotation/98612397/
作为一个老程序员，无论接口也好，依赖倒置也好，觉得自己特别的“懂”。但是站在架构的角度为什么这么做，这本书回答的很清楚。
书很薄，也容易读，周五下午书到家，周六下午读完了，整个周日都在思考接口和依赖倒置。
这本书还有个好处就是清晰的告诉你编程范式就三种：结构式，函数式和面向对象。你不知道我读完这个有多放松。好比你苦苦追剧 38 集，就等 40 集的真相大白，结果无意中听到了剧透。去你妈的，这不是吊胃口么，老子不跟了。Bob 就是这个剧透。
看完还有个思考是，按照 Clean Architecture 的设计，似乎有个假定业务是稳定的，我们外围的 Application Logic，Presentation Layer，Runtime Environment 在类似于 Onion 的结构外层。其实现实却不然，只要稍有维护经验的人都知道，简单的业务需求修改就可以跨越这些层。比如一个业务是新增业务，需要 Entity 做支撑，需要有着自己的业务逻辑和显示逻辑，包括可能需要 Environment 的 Setup 。简单说业务经常变，是不是 Clean Architecture 就不适用了？
是，也不是。如果业务一直变的情况下，而且不能预测方向的情况下我们该怎么做？我觉得有两点我们可以做：
- 注重模块化，谨慎抽象。给后期做一些准备。
- 通过使用接口，让有些依赖反转，目的是推迟做决定。
业务一直变，程序员 /架构师有办法吗？坦白讲：没有。作为程序员 /架构师我们能做些什么来改善吗？能。
BUT, WHAT IS COST OF DIP?
在几天的思考里还有个问题一直萦绕在我脑海里：DIP 的代价是什么？如果没有代价的话，我们可以随意的用 DIP 原则。再说没有什么事情是没有代价的。
不知道你们有没有见到这样的项目：不管什么需求，都先要去定义和实现接口，实现和接口在接口被定义在不同的项目(部署单元)里。如果你是类似.NET 和 Java 工程师，你肯定会见到这样的项目。这样的项目开发体验如何？
我有很多次遇到这样的项目的经历，开发和维护体验其实都及其糟糕，感觉不到任何 DIP 的好处，而是一堆神烦的约定。一个站在用例角度上的小修改，跨越好几个部署单元(DLL 或者 jar)。
调试的时候更加让人苦恼，你无法通过反馈的问题 /日志，直接通过查阅代码来预测代码的运行行为。你对着报错却“迟迟”找不到原因。报错点和实际问题点隔上好远。每次项目里小问题，都是对项目的一次大探索。
所以应用 DIP 的代价是什么？软件架构最重要的事情是什么？管理复杂度(Complexity Management)。减少不必要的意外复杂度(Accidental Complexity)。简单讲就是让本来的简单的事情保持简单。而 DIP 在引入隔离，推迟决定的同时也引入了复杂度：
the DIP comes with the complexity.
关键点是：DIP 这里引入的是必要的复杂度，还是意外的复杂度。
给那些“尽信书”的朋友： https://naildrivin5.com/blog/2019/12/02/dependency-inversion-principle-is-a-tradeoff.html
但是不妨碍，我给这本书 5 星。
rapperx2：这背景 看着刺眼
jatsz：@rapperx2 我也觉得，我发布到“阅读”频道就这样了，没有找地方调整呢。
jatsz：@rapperx2 好像换个频道就可以了，我换到“编程”频道了。
备案期间域名能解析境外吗zok2002：备案期间域名能解析境外吗，境内不解析
不严谨研究，头戴式耳机白发带revalue：头戴式耳机。最近发现平时戴“头带”的地方，白头发特别多。本人白头发不是平均分布的，就是主要分布在耳机“头带”的地方，尤其是头顶。在公司研究了一圈，玩耳机的、不玩耳机的。发现玩耳机的这一区域白头发特别猛。有没有哪位水友一起研究一下
《木兰》观后感Cyshall：除了服装和场景还可以，其余的是真的烂，太烂了，要不是因为刘亦菲真特么看不下去。Chell：觉得刘亦菲演技也一般（粉丝别打我）
有没有无糖的泡腾片？waiaan：就是想让白开水喝起来能有汽水的那种感觉（二氧化碳），不用甜的。terence4444：泡腾片的问题不在糖，而是盐。没想到吧
家人想在广西钦州龙门港镇（防城港东面）买房投资，求打醒。此处有赞nevermlnd：家人没什么钱，被卖房的朋友忽悠去那边玩了几天，就想在那贷款买期房投资。 查阅了一些资料，加上和朋友交流，不看好在那里买房投资，但是又拿不出太多有力的东西。