- 學習一系列久經(jīng)考驗的架構(gòu)實踐,從有效的架構(gòu)、設計思維與運維等方面入手,創(chuàng)建優(yōu)質(zhì)的軟件產(chǎn)品。
- 深入探索業(yè)務架構(gòu)、基礎設施架構(gòu)、數(shù)據(jù)架構(gòu)與應用程序架構(gòu)。
- 探討架構(gòu)師、項目經(jīng)理以及管理層如何通過價值鏈,與開發(fā)團隊、管理團隊和產(chǎn)品團隊高效地開展工作。
- 探討機器學習架構(gòu)與自動化流水線的特殊應用。
- 為企業(yè)架構(gòu)團隊提供一套完整的實踐模板。
為什么有如此之多的軟件項目都以失敗告終?本書的作者是一名資深的首席架構(gòu)師兼CTO,他在本書中介紹了一種全新的軟件架構(gòu)理論與實踐方法。語義設計打破傳統(tǒng)思想,重新定義了軟件架構(gòu):為構(gòu)建強大、靈活及可擴展系統(tǒng)而構(gòu)思概念的過程。
本書概述了語義軟件設計的核心實踐,并提出了一套完整的架構(gòu)實踐工具包,其中包括一組實踐模式和模板。架構(gòu)師、系統(tǒng)設計師、軟件開發(fā)經(jīng)理、CTO和CIO可以通過本書學習如何創(chuàng)建有效且全面的架構(gòu)與技術(shù)計劃,從而提高項目的成功率。
前言
感謝你選擇這本書。歡迎你的閱讀。
本書介紹了一種設計軟件的新方法。提出了一種思考如何構(gòu)建軟件的新方式。本書主要面向大型項目,特別是新建的軟件項目,或大規(guī)模舊系統(tǒng)的現(xiàn)代化改造項目。如果軟件未能控制在預算范圍內(nèi),未能在計劃時間內(nèi)交付,或沒有按照承諾交付功能,則可以稱為失敗。然而,軟件項目的失敗比率非常高,這一點毫無爭議,而且有據(jù)可查。在過去二十年間,這種情況越演越烈。為了軟件設計更加成功,我們必須尋求不同的出路。但是出路在哪里呢?
假設你正在制作業(yè)務應用程序軟件和服務,并作為產(chǎn)品出售給客戶,或者在某家公司內(nèi)部的IT 部門工作。本書不涉及導彈制導系統(tǒng)、電話通信系統(tǒng)或固件,也無意討論面向?qū)ο笈c函數(shù)式編程,而且也沒有興趣討論任何流行的框架。需要說明一點,書中提到的語義源自我接受過的哲學思想教育,因此指的是符號。我們這里所說的語義與蒂姆·伯納斯- 李提出的語義網(wǎng)沒有任何關系。
本書面向的讀者主要包括CTO、CIO、工程副總裁、各行各業(yè)的架構(gòu)師(無論是企業(yè)、應用程序、解決方案還是其他方面)、軟件開發(fā)經(jīng)理和立志成為架構(gòu)師的高級開發(fā)人員。此外,技術(shù)領域的任何人,包括測試人員、分析師和高管都可以從本書中受益。書中的代碼很少。希望經(jīng)理、領導、有求知欲的高管,以及軟件項目的從業(yè)人員能夠在閱讀本書后,理解并接受主要內(nèi)容。
對于本書提出的觀點,有些人可能會對感到驚訝,有些人甚至可能會感到憤怒。這些觀點看起來很新穎,而且對于某些人來說非常陌生,但實際上這些觀點借鑒了《設計思維導論》。我根據(jù)多年的經(jīng)驗,并結(jié)合多方面的信息,總結(jié)出了一套方法。基本思想大多源自我在讀研時期對于哲學的研究。本書概述了語義設計的思想、流程、實踐、模板和實用方法。
這種軟件設計方法已經(jīng)過檢驗,實證有效。在過去的二十年里,我有幸與很多大型全球上市企業(yè)的CTO、CIO、首席架構(gòu)師合作,設計并領導創(chuàng)建了許多大型的重要軟件項目,并贏得了多個創(chuàng)新獎項。更重要的是,我們創(chuàng)建了成功的軟件。從某種意義上來說,本書中提出的思想代表了我設計軟件的方式。我采用這種方法已經(jīng)十多年了,以此領導了大大小小的軟件項目設計。雖然與傳統(tǒng)的軟件設計思維方式截然不同,但我的這套思想并非無本之木,也不是紙上談兵,而是已經(jīng)得到了證實,確實有效。
在軟件設計中,我們不得不使用前人留下來的專業(yè)術(shù)語。但在本書中,有時我會在架構(gòu)師或架構(gòu)上劃上刪除線,比如像這樣:架構(gòu)師。意思是說,雖然迫于歷史的原因,我不得不在交流中使用這些專業(yè)術(shù)語,但它們在當前上下文所表示的含義并不準確。
本書的第一篇介紹了該方法的理念框架。我們介紹了希望解決的問題以及原因。這部分內(nèi)容大多是概念講解,為后面的章節(jié)提供了理論基礎。
本書的第二篇的內(nèi)容非常務實。我們介紹了一系列文檔模板和可重復的實踐,可在日常工作中使用。
本書的第三篇概述了管理軟件以及控制軟件混亂程度的一些方式。最Z后以一份宣言結(jié)尾,簡明扼要地總結(jié)了構(gòu)成該方法的一系列原則和實踐。
總的來說,本書介紹了一套理論框架以及實踐的方法。然而,這套理論并不是一成不變的,我在這里拋磚引玉,希望將來能夠進一步提煉和改進。
本書的創(chuàng)作源于對軟件和寫作的熱愛。希望你能喜歡本書,并將這些方法應用到實際的工作中。如果你對于這套理論有任何看法或建議,請聯(lián)系我們:eben@aletheastudio.com 或AletheaStudio.com。
排版約定
本書使用了下述排版約定。
斜體(Italic)
表示新術(shù)語、URL、電子郵件地址、文件名和擴展名。
等寬字體(Constant Width)
表示程序片段,以及正文中出現(xiàn)的變量、函數(shù)名、數(shù)據(jù)庫、數(shù)據(jù)類型、環(huán)境變量、語句和關鍵字等。
等寬粗體字(Constant width bold)
表示命令或其他用戶輸入的文本。
等寬斜體字(Constant Width Italic)
表示該文本應當由用戶提供的值或由用戶根據(jù)上下文決定的值替換。
使用代碼示例
你可以通過如下鏈接下載本書的補充材料( 代碼示例, 練習等):https://aletheastudio.com。
本書的目的是幫助你完成工作。一般來說,你可以在自己的程序或者文檔中使用本書附帶的示例代碼。你無需聯(lián)系我們獲得使用許可,除非你要復制大量的代碼。例如,使用本書中的多個代碼片段編寫程序就無需獲得許可。但以CD-ROM 的形式銷售或者分發(fā)OReilly 書中的示例代碼則需要獲得許可;卮饐栴}時援引本書內(nèi)容以及書中示例代碼,無需獲得許可。在你自己的項目文檔中使用本書大量的示例代碼時,則需要獲得許可。
我們不強制要求署名,但如果你這么做,我們深表感激。署名一般包括書名、作者、出版社和國際標準圖書編號。例如:Semantic Software Design by Eben Hewitt(OReilly). Copyright 2020 Eben Hewitt, 978-1-492-04595-3。
如果你覺得自身情況不在合理使用或上述允許的范圍內(nèi),請通過郵件和我們聯(lián)系,地址是 permissions@oreilly.com。
OReilly 在線學習平臺(OReilly Online Learning)
近40 年來,OReilly Media 致力于提供技術(shù)和商業(yè)培訓、知識和卓越見解,來幫助眾多公司取得成功。
我們擁有獨一無二的專家和革新者組成的龐大網(wǎng)絡,他們通過圖書、文章、會議和我們的在線學習平臺分享他們的知識和經(jīng)驗。OReilly 的在線學習平臺允許你按需訪問現(xiàn)場培訓課程、深入的學習路徑、交互式編程環(huán)境,以及OReilly 和200 多家其他出版商提供的大量文本和視頻資源。有關的更多信息,請訪問http://oreilly.com。
聯(lián)系我們
請把對本書的評價和問題發(fā)給出版社。
美國:
OReilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中國:
北京市西城區(qū)西直門南大街2號成銘大廈C座807室(100035)
奧萊利技術(shù)咨詢(北京)有限公司
這本書有專屬網(wǎng)頁,你可以在那兒找到本書的勘誤、示例和其他信息。網(wǎng)址是:https://oreil.ly/semantic-software-design。
如果你對本書有一些評論或技術(shù)上的建議,請發(fā)送電子郵件到errata@oreilly.com。
要了解OReilly 的圖書和培訓課程的新聞和信息,請訪問我們的網(wǎng)站,地址是:http://www.oreilly.com。
我們的Facebook:http://facebook.com/oreilly。
我們的Twitter:http://twitter.com/oreillymedia。
我們的Youtube:http://www.youtube.com/oreillymedia。
致謝
我要感謝具有敏銳洞察力的Mike Loukides,感謝你的指導和鼓勵幫助我提煉出了這些理念,并完成了本書的創(chuàng)作。很榮幸能夠與你共事,感謝你為推進我們的領域所做的一切。
感謝OReilly 的開發(fā)編輯,勤勤懇懇、一絲不茍的Alicia Young。在本書的創(chuàng)作過程中,我們之間的合作非常愉快,感謝你的付出以及提出的寶貴意見。很高興與你合作。
感謝Mary Treseler、Neal Ford、Chris Guzikowski 以及OReilly 的整個軟件架構(gòu)會議團隊。感謝你們提供的場地為我?guī)砹诉M一步探索和挑戰(zhàn)這些理念的空間和氛圍。
感謝Tim OReilly,感謝OReilly Media。
感謝Sabre 出色的企業(yè)架構(gòu)團隊。Andrea Baylor、Andy Zecha、Holt Hopkins、Jerry Rossi、Tom Murray 還有Tom Winrow,很榮幸能與你們共事,我們共同創(chuàng)造了這些優(yōu)雅、嚴謹?shù)南到y(tǒng)。感謝Jonathan Haynes 審閱早期的草稿,并提出了有關本書的修改意見。感謝Clinton Anderson 和Justin Ricketts,感謝二位給予的支持。
感謝我的父母,感謝你們激發(fā)了我寫作的興趣。
感謝我的老師們,特別是Christine Ney 和Bryan Short。非常感謝你們的諄諄教誨。
感謝Alison Brown,感謝你貢獻了許多重要的想法,感謝你給予本書的支持。本書得以付梓,離不開你付出的一切努力。
Eben Hewitt是一家全球企業(yè)SaaS公司的首席架構(gòu)師兼CTO。曾出版《Technology Strategy Patterns: Architecture as Strategy》、《Cassandra: The Definitive Guide》等多部有關架構(gòu)、服務,以及軟件開發(fā)的書籍。
目錄
前言 .1
第一篇 設計理念
第1 章 軟件架構(gòu)的起源 9
1.1 軟件的概念起源 .9
1.2 復制與創(chuàng)新 . 15
1.3 為什么軟件項目會失敗 17
1.4 失敗的影響 . 20
第2 章 概念的產(chǎn)生 .22
2.1 語義與軟件工廠 22
2.2 需求的神話 . 24
2.3 語義與軟件架構(gòu) 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 通過總體構(gòu)圖傳達概念 39
2.9.1 示例 41
2.9.2 從其他角度考慮總體構(gòu)圖 42
2.9.3 總體構(gòu)圖基于一系列發(fā)現(xiàn) 42
2.10 理解理念 44
2.10.1 感性確定性 44
2.10.2 元認知 45
2.11 上下文 . 47
2.12 集合 . 49
2.13 語義設計的優(yōu)勢 . 52
第3 章 解構(gòu)與設計 .55
3.1 解構(gòu)簡介 55
3.2 簡單的復雜 . 59
3.3 構(gòu)造與解構(gòu) . 61
3.4 功能可供性 . 63
3.5 賦予負空間意圖和使用價值 65
3.6 設計決策至少具備兩個正當理由 68
3.7 多角度設計 . 69
3.8 創(chuàng)建隔離區(qū)或大使館 . 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 小結(jié) 90
第5 章 語義設計的實踐與成果物 91
5.1 設計原則 92
5.2 結(jié)對設計 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 小結(jié) 121
第6 章 業(yè)務 122
6.1 捕獲業(yè)務戰(zhàn)略 . 125
6.1.1 提供統(tǒng)一認識 . 126
6.1.2 戰(zhàn)略目標與戰(zhàn)術(shù)需求的統(tǒng)一 127
6.2 框架介紹 129
6.3 創(chuàng)建業(yè)務術(shù)語表 130
6.4 創(chuàng)建組織圖 130
6.5 創(chuàng)建業(yè)務能力模型 131
6.6 創(chuàng)建流程圖 134
6.7 重新設計流程 . 134
6.8 盤點系統(tǒng) 136
6.9 定義指標 137
6.10 適當?shù)墓芾?138
6.11 應用程序中的業(yè)務架構(gòu) 138
6.12 小結(jié) 141
第7 章 應用程序 143
7.1 接納約束 143
7.2 解耦用戶界面 . 145
7.3 平臺設計 146
7.4 服務的資源和表示 148
7.5 API 準則 151
7.6 解構(gòu)版本編號規(guī)則 152
7.7 可緩存性和冪等性 154
7.8 可獨立構(gòu)建 155
7.9 策略模式與可配置服務 . 155
7.10 特定于應用程序的服務 157
7.11 通過服務通信 158
7.12 對外公開 . 158
7.13 彈性設計 . 159
7.14 交互式文檔 161
7.15 服務的結(jié)構(gòu) 162
7.15.1 UI 軟件包 162
7.15.2 編排 163
7.15.3 引擎 165
7.15.4 數(shù)據(jù)訪問器 169
7.16 事件處理 . 169
7.17 上下文服務與服務混合 172
7.18 性能提升檢查列表 . 174
7.19 API 與實現(xiàn)的分離 . 175
7.20 語言 176
7.21 不變性 . 177
7.22 規(guī)格 179
7.23 自動測試 . 183
7.24 注釋 183
7.25 小結(jié) 185
第8 章 數(shù)據(jù) 186
8.1 業(yè)務術(shù)語表 186
8.2 語義數(shù)據(jù)建模策略 187
8.3 多種多樣的持久層 190
8.4 多重建模 192
8.5 流數(shù)據(jù)模型 194
8.6 機器學習的特征工程 196
8.7 Classpath 部署與網(wǎng)絡代理 198
8.8 點對點持久存儲 199
8.9 圖數(shù)據(jù)庫 201
8.10 數(shù)據(jù)流水線 204
8.11 機器學習數(shù)據(jù)流水線 206
8.12 元數(shù)據(jù)與服務指標 . 209
8.13 審計 210
8.14 ADA 合規(guī)性 210
8.15 小結(jié) 211
第9 章 基礎設施 212
9.1 架構(gòu)師的考慮因素 212
9.2 開發(fā)運維 214
9.3 基礎設施即代碼 216
9.4 指標優(yōu)先 218
9.5 關注自動化流水線 220
9.6 生產(chǎn)的多元宇宙與特性開關 221
9.6.1 特性開關的實現(xiàn) 222
9.6.2 多臂老虎機:機器學習與無限切換 . 224
9.7 基礎設施設計與文檔 225
9.8 混沌工程 227
9.9 利益相關者的多樣化與內(nèi)外用戶 . 229
9.10 小結(jié) 230
第三篇 運維、流程以及管理
第10 章 創(chuàng)意總監(jiān) . 235
10.1 語義設計師的角色 . 235
10.2 各個行業(yè)的創(chuàng)意總監(jiān) 238
10.2.1 時尚界 . 239
10.2.2 影視業(yè) . 240
10.2.3 電子游戲業(yè) 242
10.2.4 廣告業(yè) . 242
10.2.5 戲劇業(yè) . 242
10.2.6 科技行業(yè) . 243
10.2.7 稱謂 245
第11 章 管理與運營 . 248
11.1 策略與工具 248
11.2 迂回策略 . 250
11.3 水平思考與概念構(gòu)思 251
11.4 概念測試 . 255
11.5 代碼審核 . 257
11.6 演示 258
11.7 運營計分卡 259
11.8 面向服務的組織 261
11.9 可擴展商業(yè)機器 266
11.10 現(xiàn)代化計劃的管理 268
11.11 變革管理 269
11.12 管理委員會 . 272
11.12.1 目標 272
11.12.2 指標 273
11.12.3 服務組合 274
11.12.4 服務目錄與元數(shù)據(jù) 274
11.13 服務設計清單. 276
11.13.1 服務設計 276
11.13.2 服務運營 277
11.13.3 業(yè)務流程 278
11.13.4 數(shù)據(jù) 278
11.13.5 錯誤 279
11.13.6 性能 279
11.13.7 安全 279
11.13.8 質(zhì)量保證 280
11.13.9 可用性與支持 280
11.13.10 部署 . 281
11.13.11 文檔 281
11.14 有關組織設計的延伸閱讀 282
第12 章 語義設計宣言 283
附錄A 語義設計工具集 295
附錄B 延伸閱讀 298