企业架构团队通常与日常开发分离。这会导致他们对开发工作的了解过时，而开发团队也没有从公司全局的角度考虑问题。我的同事（Thoughtworks 首席技术官）Rebecca 经常看到这种情况发生，她认为企业架构师可以通过加入开发团队来提高效率。

表格驱动技术允许系统在不进行重大代码更改的情况下进行更改。

咖啡师不做同步处理 - 他们的理由也可能是你选择异步处理的理由。

清晰的代码是好的，但你应该为了可测试性而牺牲清晰度吗？

如果软件要崩溃，Jim 在本专栏中解释了为什么它应该尽快崩溃。

每个人都有自己认为重要的设计准则列表。Scott 专注于接口，以及如何设计接口以便于正确使用和难以错误使用。

在 2003 年的 OOPSLA 大会上，Dave Thomas（OTI 的创始人）对模型驱动架构（MDA）进行了深刻而有力的批判。在本专栏中，他解释了为什么他认为通用的模型驱动方法可能会失败，并指出 UML 和领域特定语言仍然具有价值。

重构的日益普及、JUnit 等工具以及极限编程 (XP) 等敏捷方法的出现，带来了一种新的设计风格。持续设计是使用重构来不断改进程序设计的过程。在本专栏中，Jim 讨论了他对持续设计的经验，特别是对国际化和事务等看似棘手的设计问题的经验。

封装的一个常见部分，尤其是在面向对象系统中，是隐藏数据结构。然而，在数据访问例程的背后公开大部分数据也很常见。在本专栏中，我将介绍一些编写数据访问例程的准则。但是，不要忘记，如果可以将数据隐藏起来，通常会更好。

什么是架构，谁是架构师？这些问题似乎让每个人都非常激动。因此，在本期 IEEE 软件专栏中，我让 Ralph Johnson 来解释架构：他的定义与所有其他人的定义都相符，但没有人同意。我还谈到了两种架构师：*Architectus Reloadus* 和 *Architectus Oryzus*。

当我们考虑软件架构时，我们通常会想到它的技术架构。但还有另一个重要的架构——我们用来与软件客户沟通的架构：市场架构。忽视这种“市场架构”及其与“技术架构”的关系，可能会给开发项目带来很多麻烦。

为什么混沌理论表明组件组装可能不像看起来那么容易。

我在 IEEE 专栏中介绍了模式对理解软件设计的重要贡献。

关于何时为值创建新的用户定义类型（或类）的准则。

你可以使用基于元数据的方法来消除繁琐的面向数据任务的痛苦。

Jim 和 Alexei 在开发新版 NUnit 中发挥了领导作用。由此，他们反思了新的 .NET 语言特性——属性——如何影响设计。

许多关于性能优化的成熟原则并不为人所知，这总是让我感到惊讶。本文是又一次尝试涵盖这些原则。

许多现代语言都区分模块中的公共特性和私有特性。一个不那么常见的区别是公共特性和已发布特性之间的区别：这可能是一个更重要的区别。

有时，软件中避免重复的简单规则如何导致良好的设计，这是非常值得注意的。

我学到的第一课就是始终将用户界面代码与其他任何代码分开。这不仅仍然是一个好建议，而且令人惊讶的是，它经常被遗忘。

Craig 在本专栏中探讨了开闭原则和受保护变异的重要性，以及为什么 Parnas 的信息隐藏不仅仅是封装。他还就如何实现受保护变异给出了一些技巧。

思考如何可视化和减少耦合。

通常，设计技术用于使系统更加灵活，但最终却更难使用。其中一个原因是，在设计中经常会忘记明确性。

可测试性是一个非常重要的特性，你应该在架构决策中提高系统的可测试性。

模块化编程不仅仅是针对接口编程，还包括在各个模块不知道它们正在与哪些具体模块通信的情况下将它们组装在一起。

你绘制的模型类型取决于你想要实现的目标。John 描述了概念模型、规范模型和实现模型之间的有用区别。