BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

讨论:烦人的细节

| 作者 Abel Avram 关注 10 他的粉丝 ,译者 侯伯薇 关注 0 他的粉丝 发布于 2011年11月30日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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说到:“如果我们需要做出某些关键的技术决定,那么肯定就需要完成,是吧?”,然后他问道:“如果我没有,或者不能推迟做出决定,那就一定意味着我拥有很差的架构吗? 我们难道不应该把推迟作为一种有意识的决定,而不是一种规则吗?”

Bob大叔在从架构角度考虑的时候只关注系统的核心领域知识,而Brown的方法则与之不同,他认为“交付机制”当前是很大的一块工作,应该整合到总体架构之中,如下图所示:

image

Brown的结论是:

对我来说,架构不仅仅是包含在“应用程序”中的内容。结构很重要,但是还有很多重要的内容,像非功能性需求、实际的交付机制(技术、框架、工具、API等等)、基础架构服务(例如:记录日志、异常处理、配置等等)、集成服务(内部和外部的)、满足所有环境的限制(例如:运维和支持)等等。对我来说,所有这一切都与架构相关。

讨论并没有就此结束。Bob大叔在另一篇博文《整洁的架构(Clean Architecture)》中对Brown的观点作出响应,他说,不管用户界面和数据库部分有多大,系统的架构都不应该面向这些“较大的元素”,并且“其他部分应该与之解耦”。他继续解释说,将核心领域知识与交付机制解耦非常重要,并说他不会特意地延迟和停止作出与框架相关的决定,但是架构师应该总是可以保持这两部分清晰地分离,即便这两项工作同时进行:

我曾经做出的更尖锐的关于架构的评论是,好的架构让你可以延迟做出一些重要的决定,像用户界面、框架、数据库等等。但有些人指出,客户不希望延迟用户界面方面的工作。DBA也不希望延迟数据库方面的工作。在每次迭代完成的时候,他们都希望看到整个系统可以正常工作,包括用户界面、数据库和框架。他们不希望一次迭代只处理业务规则问题。事实上,好的敏捷实践特别要求对整体架构做“长而薄”的切分。

当然,我完全同意这一点。然而,“长而薄”的内容不需要同时进行。好的架构让你可以延迟做出重要的决定,它并不会强迫你延迟这些工作。然而,如果你可以延迟,那么就意味着你拥有更大的灵活性。例如,你可以在前面的几个sprint中创建临时的简单用户界面,然后再用更完备的用户界面来替换。

Bob大叔做出结论说:“先处理这些烦人的小细节也没什么问题,只要你能够将业务规则与它们解耦。”

Brown在对《整洁的架构》一文的回复中做出响应:他同意Bob大叔关于解耦的观点,但是在处理基础架构方面提出了不同的观点:“交付机制并非是可以延迟到‘世界末日’的烦人细节”,尽管Bob大叔坚持该工作是细节问题。Brown的结论是:

  1. 将应用程序的代码和技术解耦很不错,而且是我们应该尽力做到的。这样得到的代码更易于做单元测试、易于替代、易于维护、易于修改等等。
  2. 软件架构是与全局相关的,而应用程序的代码只是全局中的一部分。
  3. 如果你仍然把“交付机制”这样的重要决定推迟,并且不考虑如何解决重要的非功能性需求和约束,那么就不得不面临软件项目失败的风险。

在讨论中,Bob大叔和Bronw并不真的是处于对立的双方。他们都支持要清晰地分离核心领域知识与支持框架,但是前者更关注于领域知识,而后者认为还需要考虑并重视基础架构。你的方法是怎样的呢?

查看英文原文:Debate: The Annoying Detail

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

吃饱了撑的 by 江南 白衣

Brown的结论实在是几十年都没改过的基本原理了,这都拿出来重新讨论一番,太闲了吧。

菜鸟还是先修炼好各种技术内功,才可以谈得上架构。 by 陈 国栋

当你完全精确各种Java框架,数据库技术这些工具之后,就可以专注于业务领域的知识了。但是,如果你是一个完全不需要写代码的产品经理,则不需要学习那些框架了。

无聊的讨论 by Yang Bob

高度不同,看到的东西和角度不同,没啥好辩论的,从落地角度来说,必须关注框架和细节,选错了框架有可能功能无法实现,业务架构和技术架构本来就是二个东西,系统的二个层次,一个架构描述怎么能兼顾着二个方面。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT