关于架构的讨论：烦人的细节 - xiyf2046的专栏 - 博客频道 - CSDN.NET
Bob大叔和Simon Brown关于描述系统架构时基础架构（infrastructure）所起的作用展开了讨论。
在之前标题为 《尖叫的架构（Screaming Architecture）》的文章中，Robert Martin（也就是Bob大叔）阐述了这样的观点：软件产品的架构应该让所有人都很容易了解产品所要达到的目的，并且系统的架构应该反应系统的用例而不是它使用的框架：
架构不是（或者说不应该是）关于框架的内容。架构不应该由框架支持。框架是我们要使用的工具，而不是要符合的架构。如果你的架构基于框架，那么它就无法基于你的用例。
此外，好的架构应该让我们可以推迟那些不确定的，与框架、数据库、web服务器等等相关的决定，Bob大叔如是说：
好的架构让我们直到项目的后期才需要决定使用Rails，或是Spring，或是Hibernate，或是Tomcat，或是MySql等等。好的架构也让我们能够轻松地改变这些决定。好的架构强调的是用例，并把它与周边的关注点解耦。
Bob大叔还谈到了互联网，想知道那是否也应该被认为是边缘关注点，并做出结论，网络也是一种"交付机制"：
网络是一种交付机制，你的应用程序架构应该这么来对待它。你的应用程序是否通过网络交付是一种细节问题，系统结构不应该取决于此。实际上，你的应用程序是否通过网络交付是你应该推迟考虑的事情。你的系统架构应该尽可能地与如何交付无关。你应该可以把它作为控制台应用程序、web应用程序、富客户端应用程序、甚至是web服务应用程序来交付，而不需要让基本的架构过度复杂或者对其做出变更。
Bob大叔文章的结论是：你的架构应该告诉读者与系统相关的内容，而不是你在系统中所使用的框架。
Simon Brown是一位软件架构师，他对Bob大叔关于"交付机制"的观点发表了评论，称之为"烦人的细节"。 他同意Bob大叔所说的系统架构不应该是它所使用的框架，但是他还说到，他希望"看到软件架构能够落地，那就需要包括所选择的实现技术。" 关于推迟决定采用何种基础架构，Brown说到："如果我们需要做出某些关键的技术决定，那么肯定就需要完成，是吧？"，然后他问道："如果我没有，或者 不能推迟做出决定，那就一定意味着我拥有很差的架构吗？ 我们难道不应该把推迟作为一种有意识的决定，而不是一种规则吗？"
Read full article from 关于架构的讨论：烦人的细节 - xiyf2046的专栏 - 博客频道 - CSDN.NET
No comments:
Post a Comment