本节书摘来自异步社区《Microsoft.NET企业级应用架构设计（第2版）》一书中的第1章，第1.3节，作者： 【意】Dino Esposito（埃斯波西托） , Andrea Saltarello（索尔塔雷罗）著，更多章节内容可以访问云栖社区“异步社区”公众号查看

1.3 总结

架构对于现代软件来说是必需品而不是奢侈品。即使架构曾经只是附属品，现在也肯定不再是，其中的区别在于现代软件的复杂性。

我们通常会拿软件和土木工程比较，但是，当土木工程师要建一座桥时，这座桥将会建成。除此之外，这座桥总能正常使用，而且建筑成本和原先的预算相差无几。这对于很多软件项目来说并非如此。放到软件上，有时候很难确定利益相关者的承诺最终有哪些能够兑现。但可以确定的是，可能会超出原先的预算，交付的东西可能在某种程度上与预期的不同。

为什么软件会这样？

总的来说，软件开发很难像土木工程那样给出固定的规则，软件开发不是单纯的工程学，它涉及了大量的设计、创意，甚至心理学。此外，软件具有极高的动态性，它构建起来相对比较慢，却又需要和不断不断变化的业务需求保持同步。软件实践变化得如此之快，以至于任何时候都很难获得最先进的实践方法。

在本章里，我们着重探讨软件架构和架构师角色的本质。在下一章里，我们将会进一步探讨架构师在问题领域应用架构时实际要做的事情。在下一章里，我们将会更多地讨论软件项目的运作机制以及导致它们失败的可怕事情——大泥球。