Neal Ford 是 ThoughtWorks 的总监兼软件架构师。在这一集中，我们讨论了关于软件架构的所有内容，涵盖了他最近的三本书：“软件架构基础”、“软件架构：硬部分”和“构建演化架构”。我们首先讨论了软件架构的定义以及它与软件设计的关系。Neal 随后描述了与权衡相关的软件架构的两个重要法则及其原因。Neal 然后解释了为什么软件架构很困难，并讨论了困难的部分，例如找到最差的组合权衡、理解数据的重要性以及管理耦合。
当我们第一次开始使用 COM 和 CORBA 以及类似技术进行大量事件驱动架构时，我们大多仍将事务行为归于数据库，因为我们仍在与一个大型关系数据库对话。
然后，领域驱动设计出现了。该建议的一部分是有界上下文BC的想法，这意味着现在数据持久性是有界上下文的一部分。
它需要在架构级别进行隔离，这意味着现在事务性突然成为架构问题，而不仅仅是数据问题。
当您开始不得不在架构级别管理事务行为时，它会使软件架构中的很多事情复杂化，因为它真的很难建模。
这种事务性是任何一种架构中最糟糕的耦合，因为你迫使架构中越来越广泛的部分统一在一个单一的值上，基本上，事务性意味着你暂时停止宇宙以调整事物。你不能在大规模架构中真正做到这一点，或者至少不能并且仍然拥有大规模架构。
我们还注意到，在过去几年中，人们对数据、运营数据与分析数据的双重用途有了更多的认识。作为架构师，我们长期以来一直试图解决的功能障碍之一是将单一机制用于截然不同的目的。所以我们试图创建关系数据库作为所有这些知识的唯一来源，但现在我们需要用它来做所有这些报告和分析。
问题是，这可以追溯到您在架构中遇到的基本问题，即您的数据库模式是整个架构中最密集的实现细节之一。你越是让实现细节泄漏到你的架构中，你的架构就会变得越脆弱。意思是，你在某个地方做了一个改变，它破坏了一大堆东西。