- 学习一系列久经考验的架构实践,从有效的架构、设计思维与运维等方面入手,创建优质的软件产品。
- 深入探索业务架构、基础设施架构、数据架构与应用程序架构。
- 探讨架构师、项目经理以及管理层如何通过价值链,与开发团队、管理团队和产品团队高效地开展工作。
- 探讨机器学习架构与自动化流水线的特殊应用。
- 为企业架构团队提供一套完整的实践模板。
为什么有如此之多的软件项目都以失败告终?本书的作者是一名资深的首席架构师兼CTO,他在本书中介绍了一种全新的软件架构理论与实践方法。语义设计打破传统思想,重新定义了软件架构:为构建强大、灵活及可扩展系统而构思概念的过程。
本书概述了语义软件设计的核心实践,并提出了一套完整的架构实践工具包,其中包括一组实践模式和模板。架构师、系统设计师、软件开发经理、CTO和CIO可以通过本书学习如何创建有效且全面的架构与技术计划,从而提高项目的成功率。
前言
感谢你选择这本书。欢迎你的阅读。
本书介绍了一种设计软件的新方法。提出了一种思考如何构建软件的新方式。本书主要面向大型项目,特别是新建的软件项目,或大规模旧系统的现代化改造项目。如果软件未能控制在预算范围内,未能在计划时间内交付,或没有按照承诺交付功能,则可以称为失败。然而,软件项目的失败比率非常高,这一点毫无争议,而且有据可查。在过去二十年间,这种情况越演越烈。为了软件设计更加成功,我们必须寻求不同的出路。但是出路在哪里呢?
假设你正在制作业务应用程序软件和服务,并作为产品出售给客户,或者在某家公司内部的IT 部门工作。本书不涉及导弹制导系统、电话通信系统或固件,也无意讨论面向对象与函数式编程,而且也没有兴趣讨论任何流行的框架。需要说明一点,书中提到的语义源自我接受过的哲学思想教育,因此指的是符号。我们这里所说的语义与蒂姆·伯纳斯- 李提出的语义网没有任何关系。
本书面向的读者主要包括CTO、CIO、工程副总裁、各行各业的架构师(无论是企业、应用程序、解决方案还是其他方面)、软件开发经理和立志成为架构师的高级开发人员。此外,技术领域的任何人,包括测试人员、分析师和高管都可以从本书中受益。书中的代码很少。希望经理、领导、有求知欲的高管,以及软件项目的从业人员能够在阅读本书后,理解并接受主要内容。
对于本书提出的观点,有些人可能会对感到惊讶,有些人甚至可能会感到愤怒。这些观点看起来很新颖,而且对于某些人来说非常陌生,但实际上这些观点借鉴了《设计思维导论》。我根据多年的经验,并结合多方面的信息,总结出了一套方法。基本思想大多源自我在读研时期对于哲学的研究。本书概述了语义设计的思想、流程、实践、模板和实用方法。
这种软件设计方法已经过检验,实证有效。在过去的二十年里,我有幸与很多大型全球上市企业的CTO、CIO、首席架构师合作,设计并领导创建了许多大型的重要软件项目,并赢得了多个创新奖项。更重要的是,我们创建了成功的软件。从某种意义上来说,本书中提出的思想代表了我设计软件的方式。我采用这种方法已经十多年了,以此领导了大大小小的软件项目设计。虽然与传统的软件设计思维方式截然不同,但我的这套思想并非无本之木,也不是纸上谈兵,而是已经得到了证实,确实有效。
在软件设计中,我们不得不使用前人留下来的专业术语。但在本书中,有时我会在架构师或架构上划上删除线,比如像这样:架构师。意思是说,虽然迫于历史的原因,我不得不在交流中使用这些专业术语,但它们在当前上下文所表示的含义并不准确。
本书的第一篇介绍了该方法的理念框架。我们介绍了希望解决的问题以及原因。这部分内容大多是概念讲解,为后面的章节提供了理论基础。
本书的第二篇的内容非常务实。我们介绍了一系列文档模板和可重复的实践,可在日常工作中使用。
本书的第三篇概述了管理软件以及控制软件混乱程度的一些方式。最Z后以一份宣言结尾,简明扼要地总结了构成该方法的一系列原则和实践。
总的来说,本书介绍了一套理论框架以及实践的方法。然而,这套理论并不是一成不变的,我在这里抛砖引玉,希望将来能够进一步提炼和改进。
本书的创作源于对软件和写作的热爱。希望你能喜欢本书,并将这些方法应用到实际的工作中。如果你对于这套理论有任何看法或建议,请联系我们:eben@aletheastudio.com 或AletheaStudio.com。
排版约定
本书使用了下述排版约定。
斜体(Italic)
表示新术语、URL、电子邮件地址、文件名和扩展名。
等宽字体(Constant Width)
表示程序片段,以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。
等宽粗体字(Constant width bold)
表示命令或其他用户输入的文本。
等宽斜体字(Constant Width Italic)
表示该文本应当由用户提供的值或由用户根据上下文决定的值替换。
使用代码示例
你可以通过如下链接下载本书的补充材料( 代码示例, 练习等):https://aletheastudio.com。
本书的目的是帮助你完成工作。一般来说,你可以在自己的程序或者文档中使用本书附带的示例代码。你无需联系我们获得使用许可,除非你要复制大量的代码。例如,使用本书中的多个代码片段编写程序就无需获得许可。但以CD-ROM 的形式销售或者分发OReilly 书中的示例代码则需要获得许可。回答问题时援引本书内容以及书中示例代码,无需获得许可。在你自己的项目文档中使用本书大量的示例代码时,则需要获得许可。
我们不强制要求署名,但如果你这么做,我们深表感激。署名一般包括书名、作者、出版社和国际标准图书编号。例如:Semantic Software Design by Eben Hewitt(OReilly). Copyright 2020 Eben Hewitt, 978-1-492-04595-3。
如果你觉得自身情况不在合理使用或上述允许的范围内,请通过邮件和我们联系,地址是 permissions@oreilly.com。
OReilly 在线学习平台(OReilly Online Learning)
近40 年来,OReilly Media 致力于提供技术和商业培训、知识和卓越见解,来帮助众多公司取得成功。
我们拥有独一无二的专家和革新者组成的庞大网络,他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。OReilly 的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境,以及OReilly 和200 多家其他出版商提供的大量文本和视频资源。有关的更多信息,请访问http://oreilly.com。
联系我们
请把对本书的评价和问题发给出版社。
美国:
OReilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国:
北京市西城区西直门南大街2号成铭大厦C座807室(100035)
奥莱利技术咨询(北京)有限公司
这本书有专属网页,你可以在那儿找到本书的勘误、示例和其他信息。网址是:https://oreil.ly/semantic-software-design。
如果你对本书有一些评论或技术上的建议,请发送电子邮件到errata@oreilly.com。
要了解OReilly 的图书和培训课程的新闻和信息,请访问我们的网站,地址是:http://www.oreilly.com。
我们的Facebook:http://facebook.com/oreilly。
我们的Twitter:http://twitter.com/oreillymedia。
我们的Youtube:http://www.youtube.com/oreillymedia。
致谢
我要感谢具有敏锐洞察力的Mike Loukides,感谢你的指导和鼓励帮助我提炼出了这些理念,并完成了本书的创作。很荣幸能够与你共事,感谢你为推进我们的领域所做的一切。
感谢OReilly 的开发编辑,勤勤恳恳、一丝不苟的Alicia Young。在本书的创作过程中,我们之间的合作非常愉快,感谢你的付出以及提出的宝贵意见。很高兴与你合作。
感谢Mary Treseler、Neal Ford、Chris Guzikowski 以及OReilly 的整个软件架构会议团队。感谢你们提供的场地为我带来了进一步探索和挑战这些理念的空间和氛围。
感谢Tim OReilly,感谢OReilly Media。
感谢Sabre 出色的企业架构团队。Andrea Baylor、Andy Zecha、Holt Hopkins、Jerry Rossi、Tom Murray 还有Tom Winrow,很荣幸能与你们共事,我们共同创造了这些优雅、严谨的系统。感谢Jonathan Haynes 审阅早期的草稿,并提出了有关本书的修改意见。感谢Clinton Anderson 和Justin Ricketts,感谢二位给予的支持。
感谢我的父母,感谢你们激发了我写作的兴趣。
感谢我的老师们,特别是Christine Ney 和Bryan Short。非常感谢你们的谆谆教诲。
感谢Alison Brown,感谢你贡献了许多重要的想法,感谢你给予本书的支持。本书得以付梓,离不开你付出的一切努力。
Eben Hewitt是一家全球企业SaaS公司的首席架构师兼CTO。曾出版《Technology Strategy Patterns: Architecture as Strategy》、《Cassandra: The Definitive Guide》等多部有关架构、服务,以及软件开发的书籍。
目录
前言 .1
第一篇 设计理念
第1 章 软件架构的起源 9
1.1 软件的概念起源 .9
1.2 复制与创新 . 15
1.3 为什么软件项目会失败 17
1.4 失败的影响 . 20
第2 章 概念的产生 .22
2.1 语义与软件工厂 22
2.2 需求的神话 . 24
2.3 语义与软件架构 25
2.4 语义领域 27
2.5 设计就是概念生成 28
2.6 什么是概念? 30
2.6.1 达成、避免和修复 31
2.6.2 拟定概念的大纲 32
2.7 通过设计图册记录想法 36
2.8 契合目标 38
2.9 通过总体构图传达概念 39
2.9.1 示例 41
2.9.2 从其他角度考虑总体构图 42
2.9.3 总体构图基于一系列发现 42
2.10 理解理念 44
2.10.1 感性确定性 44
2.10.2 元认知 45
2.11 上下文 . 47
2.12 集合 . 49
2.13 语义设计的优势 . 52
第3 章 解构与设计 .55
3.1 解构简介 55
3.2 简单的复杂 . 59
3.3 构造与解构 . 61
3.4 功能可供性 . 63
3.5 赋予负空间意图和使用价值 65
3.6 设计决策至少具备两个正当理由 68
3.7 多角度设计 . 69
3.8 创建隔离区或大使馆 . 70
3.9 容错设计 70
3.10 设计语言 71
3.11 从用户的对立面着手 72
3.12 平台 . 72
第二篇 语义设计实践
第4 章 设计思维 77
4.1 为什么采用设计思维? 77
4.2 探索设计思维 78
4.2.1 原则 79
4.2.2 方法 80
4.3 实施设计思维方法 87
4.4 小结 90
第5 章 语义设计的实践与成果物 91
5.1 设计原则 92
5.2 结对设计 94
5.3 墙绘 95
5.4 愿景盒 98
5.5 思维导图 99
5.6 用例 . 100
5.7 准则与约定 102
5.7.1 utils 103
5.7.2 domain 103
5.7.3 service-api. 104
5.7.4 service-impl . 104
5.7.5 service-client 104
5.8 方法 . 105
5.9 设计定义文档 . 106
5.10 立场文件 . 117
5.11 RAID . 118
5.12 演示文稿和多个角度 120
5.13 小结 121
第6 章 业务 122
6.1 捕获业务战略 . 125
6.1.1 提供统一认识 . 126
6.1.2 战略目标与战术需求的统一 127
6.2 框架介绍 129
6.3 创建业务术语表 130
6.4 创建组织图 130
6.5 创建业务能力模型 131
6.6 创建流程图 134
6.7 重新设计流程 . 134
6.8 盘点系统 136
6.9 定义指标 137
6.10 适当的管理 138
6.11 应用程序中的业务架构 138
6.12 小结 141
第7 章 应用程序 143
7.1 接纳约束 143
7.2 解耦用户界面 . 145
7.3 平台设计 146
7.4 服务的资源和表示 148
7.5 API 准则 151
7.6 解构版本编号规则 152
7.7 可缓存性和幂等性 154
7.8 可独立构建 155
7.9 策略模式与可配置服务 . 155
7.10 特定于应用程序的服务 157
7.11 通过服务通信 158
7.12 对外公开 . 158
7.13 弹性设计 . 159
7.14 交互式文档 161
7.15 服务的结构 162
7.15.1 UI 软件包 162
7.15.2 编排 163
7.15.3 引擎 165
7.15.4 数据访问器 169
7.16 事件处理 . 169
7.17 上下文服务与服务混合 172
7.18 性能提升检查列表 . 174
7.19 API 与实现的分离 . 175
7.20 语言 176
7.21 不变性 . 177
7.22 规格 179
7.23 自动测试 . 183
7.24 注释 183
7.25 小结 185
第8 章 数据 186
8.1 业务术语表 186
8.2 语义数据建模策略 187
8.3 多种多样的持久层 190
8.4 多重建模 192
8.5 流数据模型 194
8.6 机器学习的特征工程 196
8.7 Classpath 部署与网络代理 198
8.8 点对点持久存储 199
8.9 图数据库 201
8.10 数据流水线 204
8.11 机器学习数据流水线 206
8.12 元数据与服务指标 . 209
8.13 审计 210
8.14 ADA 合规性 210
8.15 小结 211
第9 章 基础设施 212
9.1 架构师的考虑因素 212
9.2 开发运维 214
9.3 基础设施即代码 216
9.4 指标优先 218
9.5 关注自动化流水线 220
9.6 生产的多元宇宙与特性开关 221
9.6.1 特性开关的实现 222
9.6.2 多臂老虎机:机器学习与无限切换 . 224
9.7 基础设施设计与文档 225
9.8 混沌工程 227
9.9 利益相关者的多样化与内外用户 . 229
9.10 小结 230
第三篇 运维、流程以及管理
第10 章 创意总监 . 235
10.1 语义设计师的角色 . 235
10.2 各个行业的创意总监 238
10.2.1 时尚界 . 239
10.2.2 影视业 . 240
10.2.3 电子游戏业 242
10.2.4 广告业 . 242
10.2.5 戏剧业 . 242
10.2.6 科技行业 . 243
10.2.7 称谓 245
第11 章 管理与运营 . 248
11.1 策略与工具 248
11.2 迂回策略 . 250
11.3 水平思考与概念构思 251
11.4 概念测试 . 255
11.5 代码审核 . 257
11.6 演示 258
11.7 运营计分卡 259
11.8 面向服务的组织 261
11.9 可扩展商业机器 266
11.10 现代化计划的管理 268
11.11 变革管理 269
11.12 管理委员会 . 272
11.12.1 目标 272
11.12.2 指标 273
11.12.3 服务组合 274
11.12.4 服务目录与元数据 274
11.13 服务设计清单. 276
11.13.1 服务设计 276
11.13.2 服务运营 277
11.13.3 业务流程 278
11.13.4 数据 278
11.13.5 错误 279
11.13.6 性能 279
11.13.7 安全 279
11.13.8 质量保证 280
11.13.9 可用性与支持 280
11.13.10 部署 . 281
11.13.11 文档 281
11.14 有关组织设计的延伸阅读 282
第12 章 语义设计宣言 283
附录A 语义设计工具集 295
附录B 延伸阅读 298