很多介绍设计优缺点都是先从有点讲起，那是为了宣传，为了让别人用，我觉得对于开发者自己而言，缺点反正是最需要知道的。
个人认为：对于架构的选择，如果不能看见最直白的好处，那么就绝对不要使用，至于没有看到好处是因为真的没有好处，还是因为你的资历不够没法抓住，这都都不重要。
毕竟架构的使用因人而异，因业务而异，在选择问题上，不仅要适应公司业务发展，更需要适合自己，最后的执行人是自己，不是理论也不是别人，自己的思维能力才是自己做工作的基础，别的东西都是参考。
一 事件溯源——ES
缺点：
1 肯定需要增加更多的存储空间来容难历史数据
2 从历史数据恢复到最新状态，肯定会造成性能损失，（折衷方案）----可以使用快照
3 肯定不适合领域专家对业务事件几乎没有关注点的系统，如果使用了此架构，必然就是浪费劳动力
4 没有好的IDE和框架来支持，必须自己从头设计或者人使用别人写的类库
优点：
1 能够轻易的跟踪系统内发生的一切，事件并没有固定的结构或格式，只是一组属性，将会以某种方式持久化。
2 支持无限的业务场景可扩展性，理论上来讲，不管何时，只要领域专家提出想要关注任何事件，系统都能够轻松实现。
3 支持假设场景，通过事件存储和处理事件，你可以在任何需要的时候构建某个时间的状态，这个概念被称为事件回放，通过事件回放，业务可以知道假设场景下的状态
4 没有强制要求的技术，事件和事件溯源是架构概念，具体实现细节，由你自己来定
二 CQRS
不同于DDD，CQRS不是设计企业级系统的全面方案，只是一个模式指导你架构更大系统的特定绑定上下文。
缺点：
1 增加学习成本、和初期分析成本
优点：
1简化设计，业务的实现进行读写分离，防止不想要的操作出现在读取或写入的过程里。
2 增强可伸缩性的潜能，实现可伸缩性取决于最常执行的操作。如果是读取，就引入缓存，减少数据库访问次数；如果是吸入，可以考虑从同步写入换到异步写入甚至命令队列。
3 必须在深入理解你的应用程序读取什么和写入什么，对查询和命令的考虑，引导你按照任务和基于任务的界面进行分析，这对于最终用户来说非常友好
4 非常适合协作系统（是指那些多多用户并发访问，并应用了复杂和不断变化的业务规则）