event sourcing 不能被滥用

event sourcing 不能被滥用。我用single responsibility的例子来做个类比。
当一个类可能因为两个原因变化的时候，说明不符合单一职责原则。需要重构为两个类。
同理，如果应用中有两个方法调用，本质上是传递同一种消息，那么可以抽象出一个事件。
换种说法，只有当一个事件可能由两个以上的producer产生，或者由两个以上的consumer处理的时候，我们才认为有必要抽象出这个事件。

在物理学中，我们经常讲“场”的概念。电磁场，参照系，引力场等等。每个场有自己的规则。比如引力场中，地球和太阳的引力。不能认为太阳和地球之间存在一个“引力”的事件。
有一些方法调用，或者类之间的交互，实际上是它所在的“场”的规则。比如像转账的这样的操作，就是转账这个场景（context）的规则。目标账户，源账户，转账规则共同构成了转账场景。我们构建一个TransferMoneyContext，然后让context.run()，业务就完成了。TransferMoneyContext的run方法，应当懂得去找源账户，把钱按一定规则往目标账户去转。我狠狠的凝视着银行账户，只看到了规则，找不到事件的踪迹。

按照DCI的论文里的观点，他们认为数据结构是不容易变化的，业务方法和业务逻辑很容易变化。而好代码的标准就是，更好的隔离变化。注意，好代码的标准不是要解耦合。
DCI认为SOLID的核心是“开闭原则“，传统的OO原则使用继承，基于”李氏可替代原则“，”单一职责“，”借口隔离‘，“依赖反转”来达到“开闭原则”。
DCI批评了这种方法，提出了使用Data动态结合Role，来实现“开闭原则”。
因此，我不希望通过事件过分的解耦合。

我理解的好代码是，用最少的工作，最低的成本实现目前的需求。同时当需求变化时，需要的改动工作最少。我想这也是DDD，DCI，敏捷开发共同的目标。

作为一个对于代码量比对物价更敏感的程序员，减轻手腕的酸痛是我最关心的。任何增加手腕负担的设计都不是好设计。