“微服务架构”一词在过去几年中兴起，用于描述一种将软件应用程序设计为独立可部署服务套件的特定方式。虽然没有对这种架构风格的精确定义，但围绕业务能力的组织、自动化部署、端点智能以及语言和数据的去中心化控制都有一些共同的特征。

在 Java 社区中，涌现出大量轻量级容器，它们有助于将来自不同项目的组件组装成一个 cohesive 应用程序。这些容器的基础是它们执行连接的通用模式，这是一个它们用非常通用的名称“控制反转”来指代的概念。在本文中，我将深入探讨这种模式是如何工作的，它更具体的名称是“依赖注入”，并将其与服务定位器替代方案进行对比。选择哪种方式并不重要，重要的是将配置与使用分离的原则。

无服务器架构是一种应用程序设计，它结合了第三方“后端即服务”(BaaS) 服务，以及/或者包含在“函数即服务”(FaaS) 平台上的托管、临时容器中运行的自定义代码。通过使用这些理念以及单页应用程序等相关理念，此类架构消除了对传统始终在线服务器组件的大部分需求。无服务器架构可以显著降低运营成本、复杂性和工程交付周期，但代价是增加了对供应商依赖以及相对不成熟的支持服务的依赖。

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

一种模型（由 Leonard Richardson 开发），将 REST 方法的主要元素分解为三个步骤。这些步骤引入了资源、HTTP 动词和超媒体控件。

功能开关（通常也称为功能标志）是一种强大的技术，允许团队在不更改代码的情况下修改系统行为。它们属于各种使用类别，在实现和管理开关时，务必考虑到这种分类。开关会增加复杂性。我们可以通过使用智能开关实现实践和适当的工具来管理我们的开关配置，从而控制这种复杂性，但我们也应该致力于限制系统中开关的数量。

“模拟对象”一词已成为描述用于测试的模拟真实对象的特殊用例对象的流行词语。现在，大多数语言环境都提供了可以轻松创建模拟对象的框架。然而，人们常常没有意识到的是，模拟对象只是一种特殊用例测试对象，它支持不同的测试风格。在本文中，我将解释模拟对象是如何工作的，它们如何鼓励基于行为验证的测试，以及围绕它们的社区如何使用它们来开发不同的测试风格。

持续集成是一种软件开发实践，其中团队中的每个成员至少每天将其更改与同事的更改一起合并到代码库中。每次集成都会通过自动构建（包括测试）进行验证，以便尽快检测到集成错误。团队发现，这种方法可以降低交付延迟的风险，减少集成工作量，并支持促进代码库健康的实践，以便快速增强新功能。

在过去几年中，基于服务的架构已经转向更小、更集中的“微”服务。这种方法有很多好处，例如能够独立部署、扩展和维护每个组件，以及在多个团队之间并行开发。然而，一旦引入了这些额外的网络分区，就需要重新考虑适用于整体进程内应用程序的测试策略。在这里，我们计划讨论一些方法，用于管理多个独立可部署组件的额外测试复杂性，以及如何在多个团队各自充当不同服务的守护者的情況下，保持测试和应用程序的正确性。