Eventsourcing: 为什么人们会越来越多选择它？
为什么人们开始谈论“事件流”、“无损数据捕获”、“领域驱动设计”、“CQRS”？
让我们尝试剥离技术，让我们看看下面谎言背后的真相：
软件其实是沟通(software is communication)
Conway法则：设计系统的组织进行设计时，会受限于其组织之间的沟通联系方式。
软件项目的失败往往是因为下面三个原因的组合，每一种根源都有沟通问题：
1.软件开发构建完成后不再适合其原来目标客户了，当我们花费夜以继日地加班构建完成技术系统，而不是定期地与客户沟通，最后我们交付了伟大的技术解决方案，但是却不能满足客户要求，因而无法售出。
2.产品没有及时开发出来，错过了机会和关系甜蜜期。
3.花费在交付项目上精力和金钱超过收益。
那么，如何结束这种反产品化的沟通结构？也许是一种让我们感觉安全的需要反而产生了这些根本不希望产生的副作用。
构建软件是复杂的，是一种高度演进的过程，这个过程中能让我们感觉安全的是：对环境可控性的预期。
考虑下面多层架构，这个系统将从小型项目开始，经过几年增加新功能后不断扩大和增强：
这是一个电子商务系统，有用户注册 产品目录分类，下订单以及支付处理几个流程模块。这样的系统其模块组件如果不是充分分离，互相独立维护，而是相互有些重叠，那么随着时间的流逝，最终会变得越来越庞大、笨重和复杂。
因此，我们会引入独立团队来负责每一个模块，以确保每个团队负责的模块组件是自己可控的，这让老板和管理人员在感觉上有了一种安全感。但是导入了沟通成本。
结账/订单团队对支付团队说：你们支付处理在生产环境产生了一笔未完成的结账。
支付团队说：不知道这居然会影响结账订单系统，因为我们在iOS应用上开发新支付功能，没有时间检查。
移动产品团队说：我们需要自己定制团队，支付处理太弱了，以致不能同时在后端和app工作。
开发经理：组织结构应该改变，将所有后端开发人员集中同一个队伍，这些沟通不灵脱节的情况就不会发生了。
IT经理：让开发团队拥有自己基础设施的风险太大了，从现在开始，对任何基础设施包括数据库的改动都必须得到授权批准。
QA经理：所有系统组件经过回测后才能在产品发布单上签字。
从安全角度看，上述各种为政的想法都好像没有必要去质疑，因为系统太大太复杂，每个人做好自己责任份内的事情，一切就会变好，但是从做事情(getting-things-done)这个角度看有一个问题：没有一个部门能够不依赖其他部门独立地发布产品。
为了构建一个新功能，需要大量的协调，以及资源与优先次序的分配。结果导致更多的管理反而拖慢做事效率。沟通信息往往不是实时的，而是二手过时信息，或残缺信息导致沟通断裂。
这种组织结构虽然不能带来高效率，不利于做事，但是因为避免人们被问责而感到安全，所以，大家都愿意采取这种方式。
敏捷过程试图解决这个问题，但是常常问题牵涉到组织结构而大打折扣。如果代码库太大，以至于很难让每个人都能理解它，敏捷作用减弱了。
其实由于系统增加大小规模带来的复杂性难题已经被工业界解决；向车上旋转轮胎不需要知道化油器的工作；安全带和风扇皮带并不共享同一个带子装配； 打开行李箱不会与雨刷开关有关。我们只要借鉴这种方式就可以。
下面是这个电子商务系统的CQRS/EventSourced架构:
在这个架构下，结算订单模块与支付处理等模块子系统之间通讯是通过一种商定好的合约形式进行，这种合约形式是命令和事件。每个子模块有自己的数据库，Eventsourcing 和 CQRS 用来降低耦合。聚合是通过领域驱动设计完成，DDD是寻找出聚合，也就是所有组件都有一个自己单独职责，能够独立变化增强，不依赖其他组件，这是通过DDD的有界上下文模式实现。
这样，沟通模式会有助于交付，而不是像过去阻碍交付，项目管理变得简单得多的，因为需要让每个人一起交互相互协作的工作数量大大减少了，并有较低的复杂性。
是什么让eventsourcing、领域驱动设计和CQRS如此吸引人?它可以大大简化软件构建，保持子系统干净地分离，并能随着时间的推移各自独立维护和添加更多功能，类似于汽车、航天器和烤面包机这些工业行业。当和敏捷交付的方法结合可以非常高效的同时感觉更安全取代“传统”的架构。同时意识到，事件数据会对大数据分析和机器学习有益，因而eventsourcing 将大有可能会越来越受欢迎。