神奇的是，设计模式没有什么神奇的。
许多被认为是复杂的模式在表面下反而显得很简单，甚至是容易的。
- 以事件源为例：简而言之，你可以在流的末端追加事件，然后从流中读取所有事件。所以要追加关于对象或流的新的业务事实，然后读取所有的事件，并从中建立当前的状态，这样才能知道发生了什么，并做出下一步的决定。
- 或者CQRS：你只是按业务操作来切分你的应用程序，并把它们分成两个行为：读取和写入业务逻辑。
- 或者Outbox模式：你在同一个数据库事务中把消息和状态变化叠加在一起，然后用重试等方式异步发送消息，以确保全局流的一致性。
然而，这些模式并不容易解释，因为要把所有的要点联系起来并不容易。
"给我看看真正的生产代码"，我经常听到这样的话。
但是如果要学习模式，你就需要孤立的例子来练习和理解它们。然后，我们需要投入更多的精力来练习组合这些模式的技能。
直接进入别人的代码并不能教会你正确使用模式，因为你看到的是已经进行了权衡设计的结果！你很难理解他们是故意还是无意地应用这些模式的。
在你用吉他演奏独奏之前，你需要学习音阶、和弦和节奏。
如何学习设计模式？
当我们学习模式时，我们应该去了解原始材料。阅读原作者的想法。理解设计它的预期背景上下文。我们可能会相当惊讶。很多时候，你可能会意识到，我们玩的是中国式的耳语。
学习的最好方式是通过实践。在一个较小的规模上进行实验，了解权衡，尝试不同的配置，并将其投入生产，清洗，冲洗，重复。
例如，当我开始学习事件源时，我创建了一个样本库，以了解模式和工具，而不破坏我工作中的系统。我尝试在沙盒环境中玩不同的想法。一旦我觉得更舒服了，我就把有用的东西带到一个常规项目中。然后，我继续进行下一步的迭代，对其他我想深入探索的东西进行研究。
解决问题
每件事情都有优点和缺点：
我们不要总是用技术手段来解决一些问题，要相信一些工具会神奇地解决我们的用例。
我经常看到，人们不知道他们要解决什么问题，却已经选择了一个技术栈，然后，他们试图将模式的定义与所选择的工具相挂钩。
提炼出模式，并思考它如何与其他模式组合，它在哪些方面可以很好地工作，在哪些方面可能会失败。然后找到最好的匹配工具来帮助你。
意识到这一点应该使你成为一个更好的开发者和架构师。你将能够做出正确的决定并理解你所做的权衡。
复杂性来自权衡
架构是这样的：
你需要学习基本模式，然后分析如何将它们连接起来。
我们习惯于看到复杂性，以至于当我们面对孤立的模式时，我们会说 "它不可能那么简单！"。
实际上，它通常是简单的，但这并不总是意味着它很容易：
与其他模式的组合以及与现实世界的权衡带来了复杂性。