这一节的原则也非常清楚，而且这个比喻非常贴切。把编程比做了夜路开车。那么这里面实际上有三层含义：
一是要先前看，我们总要看清楚前进的方向；
二是不要看得太远，看得太远没有意义；
三是看到哪里是合适的？看到能看清楚的未来。(前灯照射的范围)
强调的是什么？是不做无意义的想象中的推测，并基于推测设计方案，他往往会使我们的方案和实现过于复杂，然而这些复杂的设计除了带来更多的潜在问题，更难维护的代码，更低的性能，基本带不来太多业务收益。
我举两个这两天看到的例子。一个更偏向于产品设计层面，另一个偏向于技术设计层面。
先说第一个，昨天在做上下层传递费用的简化，因为我们在费用设计中采用了金额与计费方式分离的领域设计(这个设计已经过于复杂，实际用处微乎其微)。然后在上下层消息设计中我们沿用了领域设计的关系，在传递一笔300块月结费用，和一笔500块现结费用的时候，实际上传递了四个对象加上两个对象关系，分成了两组消息分别发送。导致了接收方处理不仅要考虑处理四个对象和对象关系还需要考虑处理的时序。问题是发送方和接收方都是我们自己，锅都没地方甩。
简明的消息处理就是发送两笔钱，每一笔钱标明金额和结算方式，接收方同样会变得非常简单。在领域设计暂时不变的情况下，大大简化消息的处理。实际上我们目前都没有任何一个客户需要同时传递两笔钱分属不同结算方式的情况出现，更别说出现三笔钱，两种结算方式，然后做多对多金额分配的自己把自己搞死的情况。
再说第二个，昨天看了一下从我们另一个系统同步地理信息到我们系统的设计。整条通路是这样的。
外部系统在地理信息发生变化的时候将变化放到一个队列中，然后这个队列做了分区，也就是有十五个队列可能包含这个变化消息，然后我们监听了这15个queue，并把他合并回到了一个topic中，然后有另外一个程序监听这个topic并把它放到准备发送到我们系统的queue中，另外一个程序监听了这个queue，经过一系列处理后生成一个FTP文件放到了我们的服务器上。我们有另外一个程序监听FTP目录，把文件再放到又一个queue中，最终我们有一个程序监听这个queue按照逻辑放入我们的数据库。
请问这个流程一共经历了多少通道？有哪些是真正有业务价值的？
而这一整套通路要同步的地理数据一共大概不到一万条，每天更新的量我估计少于100条。
很巧这两个例子都是消息处理，希望我们的消息处理能够秉承简单，清晰，够用就好的思路持续做做减法重构。
网友评论