每当我和团队谈起软件架构，都有一个被反复问到的问题，TDD2 、BDD3 、DDD4 、RDD5 等技术跟架构的关系如何？这个问题其实是问xDD是否是“软件架构”的替代，特别是在“敏捷环境”中。简短的回答是否定的。稍长的回答是，思考软件架构的过程其实是确定范围，在范围之内你可以用任何一种xDD和你喜欢的敏捷实践来构建软件。
2 测试驱动开发，http://en.wikipedia.org/wiki/Test-driven_development 。
3 行为驱动开发，http://en.wikipedia.org/wiki/Behavior-driven_development 。
4 领域驱动设计，http://en.wikipedia.org/wiki/Domain-driven_design 。
5 责任驱动设计，http://en.wikipedia.org/wiki/Responsibility-driven_design 。
对我来说，原因很简单：你需要思考架构的驱动力 （影响最终软件架构的重要事情），包括下面这些。
- 功能需求 ：需求驱动架构。不管怎么捕捉和记录需求（比如，用户故事、用例、需求规格书、验收测试等），你都要大概知道你在构建什么。
- 质量属性 ：非功能需求（比如，性能、可扩展性、安全等）通常是技术方面的，也很难改造。理论上，这些都需要体现在初始的设计中，忽视这些属性会导致软件系统要么做得不够，要么做得太过。
- 约束 ：约束普遍存在于现实世界，包括批准的技术清单、规定的集成标准、目标部署环境、团队规模等。再说一次，不考虑这些会导致你交付的软件系统与环境不匹配，增加不必要的摩擦。
- 原则 ：是在试图为软件提供一致性和清晰度时你想要采用的东西。从设计的角度来看，这包括你的分解策略（比如，层、组件和微服务的对比）、关注点分离、架构模式等。明确概述一套初始的原则至关重要，这样构建软件的团队才会朝着同一方向出发。