系统架构 | 设计恰如其分的架构

远在2009年,Martin Fowler与Rebecca Parsons在QCon SF做了一次题为Agilists and Architects: Allies not Adversaries Presentation的演讲。演讲主要讨论了在敏捷方法中的架构活动。相似的话题,Neal Ford则提出了紧急设计的概念,并发表了名为Evelutionary Architecture and Emergent Design(演进架构与紧急设计)的系列文章。这是很棒的一个讲解演进架构的系列文章,谈到了TDD、代码复用、连贯接口、DSL、重构、惯用法模式、指标等与演进架构和紧急设计有关的内容。

Neal Ford对软件架构的主要观点基于如下事实:

  • 未来是不可预测的;
  • 软件设计的最终目标是获得完整的源代码;
  • 系统的复杂度分为偶发复杂度(accidental complexity)与本质复杂度(essential complexity);

于是,我们应该选择在最后责任时刻(Last Responsible Moment)去应对系统的复杂度。所谓“最后责任时刻”,即我们如果未及时采取措施,可能导致复杂度线性增加的时刻,如下图所示:

Ford提出的方法就是在开发中善于发现抽象与模式,并借助测试驱动开发,利用重构去导向设计。同时,我们还可以尝试使用一些考量代码质量的工具,获得质量指标,通过这些指标去发现问题(这些问题其实就是技术债),然后去及时解决问题。针对较难做出的架构决策,则可以利用Spike方式快速得出结论,甚至是原型方案。

事实上,演进式架构这个话题已经是老调重弹。让我们再回到2004年,Martin Fowler当然发表了文章Is Design Dead。文中谈到了计划式设计与演进式设计之间的区别。这篇文章算得上是溯本清源。在2007年我自己的书《软件设计精要与模式》中,也简单阐述了我对二者的理解。我给出了一个建筑学的隐喻:拙政园与周庄。拙政园是计划式设计的典范,没有详尽的计划,也许就不会有疏朗典雅的拙政园。周庄却并非某人在某一时刻灵感捕捉后的设计成果,而是经历了数百年的历史沧桑,渐进地增添与更替各种建筑,最后形成现在这般灵秀的水乡风貌。我在书中写道:

演进的设计,同样需要遵循架构设计的基本准则,它与计划的设计唯一的区别是设计的目标。演进的设计提倡满足客户现有的需求;而计划的设计则需要考虑未来的功能扩展。演进的设计推崇尽快地实现,追求快速确定解决方案,快速编码以及快速实现;而计划的设计则需要考虑计划的周密性,架构的完整性并保证开发过程的有条不紊。

2010年,我翻译了George Fairbanks的著作Just Enough Software Architecture。

书中除了计划式设计和演进式设计之外,还提到了第三种设计:Minimal planned design(最小计划设计),这算是一种中庸之道的选择。书中认为,演进式设计需要与一些敏捷实践配合,包括重构、测试驱动设计与持续集成。George认为计划式设计背后隐藏的思想是在构造开始之前,制订的计划可以设计出很好的细节。他还提到:

当架构为并行的多个团队所共享时,计划式架构设计就具有实践意义,在子团队开始工作之前,这种计划式设计颇为有效。

书中还写道:(对于多团队开发而言)计划式架构定义了高层的组件与连接器,并与局部的设计相匹配,而子团队则设计这些组件与连接器的内部模型。架构常常会保证整体的不变量与设计决策,例如建立并发策略、连接器的标准集、分配高层职责或定义某些局部的质量属性场景。

最小计划设计,则介乎于演进式设计与计划式设计之间。支持这种设计的人认为:如果完全采取演进式设计,可能会使得设计走向死胡同;而计划式设计又非常难,因为事先对系统并没有全面的了解,可能导致设计错误。在2002年Bill Venners对Martin Fowler的采访中,Martin Fowler认为,最合理的分配是20%的计划式设计,80%的演进式设计。在George的书中,作者认为需要权衡计划式与演进式设计。一种做法是在项目初期进行计划式设计,确保架构能够处理最大的风险。之后,就可以通过局部的设计来应对需求的变化,或者采用演进式设计,通过推行重构、测试驱动设计与持续集成对架构进行演化。

博客coding the architecture上的一篇文章Just enough architecture,从方法学的角度分析如何获得恰如其分的架构。

文章以及上图所表达出来的含义是:传统的瀑布式采取事先设计的做法,可以认为是计划式设计;敏捷方法学倾向于演进式设计;处于其中的RUP则更像是前面提到的最小计划设计。文中主要还是关注我们在架构过程中如何做到架构的“just enough”。事实上,这一观点在George Fairbanks的著作Just enough software architecture中被反复提到,要做到这一点,就需要采用风险驱动模型(Risk-Driven Model)。RDM的架构步骤分为三步:

  1. 识别风险并进行优先级排列
  2. 选择并应用相关技术
  3. 评估风险是否降低

其实风险驱动模型的三个步骤很容易理解,关键是我们应该如何识别风险,如何排列优先级,又该如何确定解决或控制风险的技术,并进行合理地评估,这是风险驱动模型的难点。我认为RDM带来的益处在于它给出了一个非常具有实践意义的驱动原则与方法,它告诉架构师,当我们在对系统进行架构时,需要从一开始就要重视风险,例如系统的安全性、可伸缩性、安全等诸多与质量属性有关的技术风险。

整体而言,这三种方式的设计各有优劣,我们应根据具体的场景,具体的项目,具体的团队进行针对性地分析。应该把握“因地制宜”的原则,认识到不同的项目需要不同的设计方式。对于不同的开发团队,做出的选择也会不同。例如,如果开发团队精于重构、测试驱动设计,并能很好地实施持续集成,就可以考虑采用演进式设计或最小计划设计。

我个人较倾向于Minimal planned design,至于它在演进式设计与计划式设计之前的权衡,不必完全照搬Martin Fowler给出的比例。参考DDD的分类,我将计划式设计的部分规划到战略式设计中,此时,我可以从用例出发,引入Bounded Context来寻找系统的核心领域与子领域。

通过Context Map并结合六边形架构,可以帮助我们识别Context或者说领域之间的通信方式与集成方式,从而获得整个系统的分布式架构模型。运用分层架构以及六边形架构驱动得出的Port与Adapter,可以帮助我们获得整个系统的应用逻辑架构。而Context自身,则可以作为业务逻辑架构的基础。

软件系统的质量属性算是特殊的一部分,可以借鉴质量驱动设计或风险驱动设计,来确定满足质量属性的架构方案。在这个过程中,我们可以参考常用的架构风格与架构模式。例如针对大数据处理、并发处理、资源管理、分布式架构,都有许多相应的模式与风格可供我们选择。架构风格与架构模式的选择,会直接影响到我们的系统架构。

当我们分别有了物理架构、应用逻辑架构与业务逻辑架构之后,计划式设计的过程就可以画一个句号了。由于我们有了Context作为领域边界,使得我们能够更好地划分特性团队。如DDD所述,团队之间的关系可以参考Context Map,例如Partnership、Consumer-Provider等。之后的过程就进入了DDD的战术设计层面。在这个层次,我们可以结合团队成员的能力来选择不同的设计方法。例如,可以选择DDD方法继续对子领域进行领域建模;也可以从Application层面,通过用例驱动设计,结合CRC卡和时序图进一步细化;当然,也可以通过ATDD与TDD进行测试驱动。

无论选择何种方式,我们的设计都应该把握“恰如其分”这个原则,不做不必要的“过度工程”。这或者可以看做敏捷架构的中心原则。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2014-09-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构

通往架构师路上的经验总结前言:困扰架构师日常问题

我先介绍一下我的新同事,据说他是美国篮球运动员詹姆斯的死忠粉,公司好多同事都这么叫他James,有8年开发经验的架构师,之前在AL待过,我一听说是AL的,啧啧啧...

492
来自专栏大数据文摘

高盛最新调查:Python超过汉语成为未来最重要技能,你准备学哪种编程语言?

1292
来自专栏java一日一条

不要和一种编程语言厮守终生:为工作正确选择

我们程序员在着手一个项目时,需要做的关键决定之一就是选择一种语言,或一组语言,用于实施该系统。这一决定不仅会影响系统的实现,也会影响设计。例如,我们应该使用面向...

582
来自专栏大数据文摘

数据科学中“专业化”意味着什么

1164
来自专栏AI科技评论

盘点丨入门必读 机器学习六大开发语言

机器学习的初学者,普遍需要面对一个问题: 到底学习哪个编程语言? 答案可能会让你惊讶:对高手来说,这关系不大。只要你了解所选语言的机器学习库和工具,语言本身其实...

3508
来自专栏CSDN技术头条

Facebook创建新开源组织TODO,Google、Twitter等继续捧场

继WebScaleSQL后,Facebook继续加大在开源界的投入。在本周一的旧金山的@Scale会议上,Facebook宣布了两项开源领域的努力——用以帮助公...

1565
来自专栏哲学驱动设计

《架构师》反思:软件架构设计

最近在看《软件架构师教程》,今天就第五章《软件架构设计》总结一下,其中还有自己所联想到的。主要从以下几个方面来描述: 软件架构 ABSD 架构模式 DSSA...

17110
来自专栏数据和云

SQL审核与开发的博弈

昨晚在恩墨微信讲堂分享了一个主题:来自真实世界的SQL优化案例。这是在Oracle 38周年纪念大会上我分享的主题,在这里和更多的朋友分享。 在分享之后,很多朋...

2684
来自专栏EAWorld

警惕文化空谈的陷阱,落地DevOps工具才是关键

恍惚间,DevOps已经被讨论十年了 “如果系统是集中式的、环境是同质化的,从开发环境向生产环境推送程序变化的过程非常简单,不需要太多的自动化;但是今天的应用需...

3335
来自专栏程序员的SOD蜜

架构重构改善既有代码的设计

(本文摘自2010技术应用计划相关章节)     当架构模型进行迭代的过程中,必然伴随着对模型进行修改和改进。我们如何防止对模型的修改,又如何保证对模型进行正确...

2666

扫描关注云+社区