
38
|
第
3
章
设计持续交付的架构
我在这方面参考了
Simon Brown
的
C4
模型(
https://c4model.com/
),他在
Software
Architecture for Developers
(
Leanpub
)(
https://leanpub.com/u/simonbrown
)一书中
详细介绍了这一模型。
总结
通过本章你应该已经了解,架构会对持续交付软件系统的能力产生以下巨大的影响 :
y
要创建一个有效的、可维护的架构,核心是要设计高内聚、松耦合的系统。
y
高内聚、松耦合会影响整个
CD
的过程:在设计阶段,高内聚系统更容易被理解;
在测试阶段,松耦合系统可以轻松用模拟来替换,将被测试的功能隔离开来 ;松
耦合系统中的模块或者服务可以单独进行部署 ;一个高内聚的系统通常也是一个
更易于被观察和被理解的系统。
y
糟糕或随意设计的架构,会限制技术和业务的发展速度,并降低
CD
构建管道的
有效性。
y
自上而下地设计
API
,由于它们提供了自动化的接口,所以有助于测试和持续交
付。
y
Heroku
的
Twelve-Factor App
总结了一些架构原则,有助于实现一个可持续交付
的系统。
y
培养机械同理心(了解应用程序平台和部署模块,以及面向失败进行设计)是如
今
Java
开发人员需要掌握的基本技能。
y
软件开发领域出现了一种新的趋势,即设计由多个小型的、可独立部署的(微)
服务组成的系统。由于高内聚和松耦合的特性,这些系统会更加适于持续交付。
同时,这些系统也需要通过持续交付来保证不断满足新的功能性和非功能性需求, ...