问高级体系结构

EN

我和Kent Beck争论过不止一次，他会说你错了，你不需要做出这些架构决策，或者更确切地说，你应该选择最简单的事情，可能会工作，并从那里开始。

我看到的问题是，在你发现STTCPW实际上不会工作之前，你可能已经走了很长一段路，给你留下了大量的返工。现在，如果你正在以增量的方式正确地做事情，或者更好地使用风险驱动的模型，所以你首先检查风险最大的决策，那么希望你能相对较早地发现这些事情，但肯定不能保证。

另一方面，很多敏捷项目所处的环境中，大多数架构都是预先确定的，例如Ruby on Rails或J2EE。这些系统极大地降低了风险，因为您有一个确定的环境。

我不知道关于这个主题的任何特定书籍，尽管我正在考虑写一本；这在敏捷社区中仍然有很大的争议。

可能我最喜欢的论坛是Martin Fowler's bliki和InfoQ，但我要警告的是，我即将开始在infoQ上发帖，所以可能会有偏见。

关于这个主题的一篇很好的文章是Martin Fowler写的"Who needs an architect?"。

我个人的观点是，您可能需要预先做出比您想象的少得多的架构决策。如果你只是做了足够的工作来做出合理的估计，你应该做得很好。

不过，您需要密切关注设计力量，并善于重构。你会希望尽早开始练习它。没有提前提出架构应该会给你很多机会。;)

你会做出错误的决定吗？是。改变架构需要时间吗？好的。

但是您也节省了大量的时间，因为您不需要预先构思一个架构。而且，因为在项目开始时你拥有的信息量最少，所以无论如何，前期架构并不是真正的“正确”。幸运的是，它将“只是”过度杀伤力，更有可能的是，还会有一些决定，你最好以后也改变。

关于风险，记住你应该首先开始开发最重要的特性。这样，您的体系结构实际上将被构建为最好地支持最重要的功能，这正是它应该采用的方式。

关于这个主题，你可能会喜欢的一本好书是Robert Martin的“敏捷软件开发-原则，模式，实践”。

在一般架构上，你有以下几个例子：

• Fowler: Pattern of Enterprise Application Architecture
• Hohpe: Enterprise Integration Patterns
• Zachman framework
• The Open Group Architecture Framework，TOGAF

你有一些特定于平台的书，例如java：

JEE Study Guide

• Broemmer：

最佳实践的太阳认证架构师

维基百科在software architecture上有一个相当全面的指针列表。