对于许多短暂接触过极限编程的人来说，XP 似乎宣告了软件设计的消亡。不仅许多设计活动被嘲笑为“前期大设计”，而且 UML、灵活框架甚至模式等设计技术也被淡化或完全忽略。事实上，XP 涉及大量的设计，但它采用的方式与已建立的软件流程不同。XP 通过允许演进成为可行设计策略的实践，重振了演进式设计的概念。它还带来了新的挑战和技能，因为设计人员需要学习如何进行简单设计、如何使用重构来保持设计的整洁，以及如何以演进的方式使用模式。

在过去十年中，我们开发并完善了许多技术，允许数据库设计随着应用程序的开发而演进。这对于敏捷方法论来说是一项非常重要的能力。这些技术依赖于将持续集成和自动化重构应用于数据库开发，以及 DBA 和应用程序开发人员之间的密切协作。这些技术适用于预生产和已发布的系统，也适用于全新项目和遗留系统。

当面临替换现有软件系统的需求时，组织通常会陷入技术替换半途而废的循环中。我们的经验教会了我们一系列模式，使我们能够打破这种循环，这些模式依赖于：刻意识别替换遗留软件的预期结果、将这种替换分解成多个部分、逐步交付这些部分，以及改变组织文化以认识到变化是不变的现实。

架构不必是独白，也不必是由少数集中的人自上而下地传达。本文描述了另一种架构方式：作为一系列对话，由分散和授权的决策技术驱动，并由四种学习和协调机制支持：决策记录、咨询论坛、团队原则和技术雷达。

近年来，关于无模式数据的优势的讨论越来越多。无模式是人们对NoSQL 数据库感兴趣的主要原因之一。但是，无模式涉及许多微妙之处，无论是在数据库还是内存数据结构方面。这些微妙之处体现在无模式的含义以及使用无模式方法的优缺点上。

最近，我的同事 Neal Ford、Rebecca Parsons 和 Pat Kua 写了一本名为“构建演进式架构”的书。我很荣幸他们邀请我为这本书写前言。

任何读过我文章的人都知道，我是演进式设计的坚定拥护者。尽管我对这种方法充满热情，但没有一种技术是完美的，我很乐意指出它的问题和成功之处。

资产捕获是开发绞杀者应用程序的一种策略。您可以将许多应用程序视为管理一组关键资产。工资系统负责员工，交易系统负责交易，租赁系统负责租赁。要逐步切换到新系统，您可以先确定将从新系统开始使用的一部分资产。通常，最适合开始的资产是简单的资产（因为它们可以快速启动）或那些使用旧系统难以处理需求的资产。

精心设计软件值得吗？

领域驱动设计是一种软件开发方法，其核心是围绕对领域流程和规则有深入了解的领域模型进行编程。该名称来自 Eric Evans 2003 年出版的一本书，该书通过一系列模式描述了这种方法。从那时起，一个从业者社区进一步发展了这些想法，催生了各种其他书籍和培训课程。这种方法特别适用于需要组织大量混乱逻辑的复杂领域。

SOA 可以用敏捷方法来做吗？

在听到有关团队使用微服务架构的故事时，我注意到一个常见的模式。

1. 几乎所有成功的微服务案例都是从一个变得过大的单体开始，然后将其分解。
2. 几乎所有我听说过的从头开始构建为微服务系统的系统，最终都陷入了严重的麻烦。

这种模式导致我的许多同事认为，即使您确定您的应用程序足够大，值得使用微服务，也不应该从微服务开始一个新项目。。

在许多组织中，预计任何持久性数据都将存储在由中央数据库管理组管理的关系数据库中。进行这种集中控制的原因有很多，通常是为了使用集成数据库。中央数据组担心的是防止格式错误的数据、可能降低重要共享资源速度的查询以及整个企业中数据模型的一致性。

这些目标可能是值得的，但其后果之一是存储数据需要相当多的繁文缛节。我经常听到关于更改订单需要数周时间才能向数据库添加列的抱怨。对于习惯于短周期演进式设计的现代应用程序开发人员来说，这种繁文缛节太慢了，更不用说太烦人了。

因此，应用程序开发团队告诉我，他们使用NoSQL 数据库来绕过 DBA。他们在这里使用的是“仅仅是数据存储”，而不是“合适的数据库”，这很有帮助。这样，DBA 就可以被排除在外，通常不会被告知或乐于不去关心。

对影响所有使用者的接口进行更改需要两种思维模式：实现更改本身，然后更新所有使用位置。当您尝试同时执行这两项操作时，这可能会很困难，尤其是在对具有多个或外部客户端的已发布接口进行更改时。

并行更改，也称为扩展和收缩，是一种以安全的方式对接口实现向后不兼容更改的模式，方法是将更改分为三个不同的阶段：扩展、迁移和收缩。

您坐在会议室里，思考着您的团队在过去几年里一直在编写的代码。您已经决定，现在能做的最好的事情就是扔掉所有代码，在一个全新的架构上重建。您对那些注定要被淘汰的代码、您花费在上面的时间以及您很久以前做出的决定有什么感觉？

在面向对象的最早期，像我这样的面向对象倡导者非常重视支持重用。早期，我们谈论的是类的重用。然后我们发现，重用单个类虽然在某些情况下有效，但在其他情况下效果不佳。因此，我们开始使用可重用框架，这为我们提供了部分构建的功能应用程序。

使用 Web 服务的好处之一是，它可以帮助您解耦系统的各个部分。人们可以在一定程度上分离地处理不同的代码库。尽管您获得了一定的解耦，但您不能完全消除耦合，因为服务仍然必须通过其接口相互通信。可悲的是，许多团队使这种耦合比应有的程度更糟。

YAGNI 最初是一个首字母缩略词，代表“You Aren't Gonna Need It”（您不需要它）。这是极限编程中的一句口头禅，通常在敏捷软件团队中使用。它指的是，我们认为软件将来需要的某些功能现在不应该构建，因为“您不需要它”。