Clean Architecture 無瑕的程式碼-整潔的軟體設計與架構篇 + 實作篇-在整潔的架構上弄髒你的手, 2/e (雙書合購)
- 出版商: 博碩文化
- 出版日期: 2024-01-01
- 定價: $1,180
- 售價: 7.6 折 $900
- 語言: 繁體中文
- ISBN:
- ISBN-13: PG00004
立即出貨 (庫存 < 9)
買這商品的人也買了...
-
$480$379 -
$580$452 -
$940$700 -
$790$616 -
$1,200$948 -
$680$530 -
$720$562 -
$680$537 -
$980$774 -
$500$390 -
$980$774 -
$354$336 -
$680$612 -
$408$388 -
$839$797 -
$750$713 -
$600$420 -
$580$458 -
$650$487 -
$680$530 -
$620$490 -
$850$663 -
$790$624 -
$850$672 -
$680$530
相關主題
商品描述
《名家名著》00
《無瑕的程式碼──整潔的軟體設計與架構篇》
工程師︰我已經拜讀了《Clean Code》,還有必要讀《Clean Architecture》嗎?
架構師︰喔,你會做磚頭,那你會蓋房子嗎?
將近10年的等待,全球知名作家Uncle Bob終於推出新作品《Clean Architecture》,由書名很容易就能猜到,這本書和《Clean Code》一定有關。沒錯,這兩本書是有些相同,但又有很大的不同。相同之處在於,這兩本書都是在教導軟體工程師如何正確開發出好的軟體,甚至兩本書提到的原則名稱有些還是相同的。不同之處在於,即便是相同的原則,但在不同層次上使用時,要注意的地方截然不同。
總結來說,好的軟體系統始於整潔的程式碼(clean code),但光是這樣還不夠。也就是說,如果磚塊做得不好,那麼建築物的架構也就不重要了。但就另一方面來說,你也能用精心製作的磚塊來製造大量的垃圾,這本書就是要避免你製造垃圾。
因此,除了閱讀《Clean Code》之外,你還需要閱讀《Clean Architecture》!
再次地,Robert C. Martin以大師強而有力的口吻,極具說服力的文字來撰寫這本書,透過這本書教您如何建構好軟體的架構,釐清什麼是架構,以及認清獨立部署和獨立開發的重要性。如果您想開發的是企業級的軟體,那就千萬不可錯過這本書。
本書將徹底顛覆您的許多觀點,例如微服務是個架構嗎?C語言沒有多型嗎(多型是物件導向發明的嗎)?C語言和C++的封裝相比,誰比較完美?軟體是數學還是科學?什麼是測試的本質?你應該使用框架嗎?關聯式資料庫為何會流行,是否已日暮途窮了呢?你可以先試著回答這些問題,然後在閱讀本書之後,再次審思這些問題,相信大多數的人,要答對一半都很困難。
如果您自許成為一位專業的軟體工程師,強烈建議您,一定要好好詳讀這本書。
~~~~~~~~~~~~~~關於架構~~~~~~~~~~~~~~
架構代表了塑造系統的「重要」設計決策,有多「重要」則是由因應變化的成本來衡量的。
Grady Booch ──《Object-Oriented Analysis and Design with Applications》作者
如果你認為好架構的代價是昂貴的,那不妨試試糟糕的架構。
Brian Foote and Joseph Yoder ──《Pattern Languages of Program Design 4》作者
架構是你希望在專案早期就能得到的決定,但你並不一定能比其他任何時候更容易得到它們。
Ralph Johnson ──《Design Patterns: Elements of Reusable Object-Oriented Software》作者
架構是一個假設,需要透過實作和度量來證明。
Tom Gilb ──《Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguag》作者
走得快的唯一方法就是走得好。
Robert C. Martin── 軟體大師,《Clean Code》、《無瑕的程式碼》系列書作者,
會做磚頭有什麼了不起,會蓋房子才厲害。
《博碩文化》、《名家名著》 總編輯 ── 陳錦輝
[名家名著] 29
Clean Architecture實作篇:在整潔的架構上弄髒你的手(第二版)
Get Your Hands Dirty on Clean Architecture - Second Edition
『針對Clean Architecture 的實作方式,這是Teddy 讀過解釋得最清楚的單一本書,推薦給有志讓軟體變軟的鄉民們。』
-「搞笑談軟工」板主Teddy Chen 二版推薦序專文推薦
『Teddy 建議搭配Uncle Bob 的《Clean Architecture》,一本學理論,另一本學實作,兩本一起服用學習效果更佳。』
-「搞笑談軟工」板主Teddy Chen 一版推薦序專文推薦
『只有誠實地面對專案需求與團隊情況,根據當下條件選擇合適的架構與方法論,並在開發與維護過程中保持敏捷的彈性,隨時回頭審視、做出調整,以便因應業務領域在未來的任何變化,才能逐步邁向業務目標。這就是軟體開發上的「風險管理」。』
-錢亞宏 譯者審校序專文推薦
軟體設計的可維護性(maintainability)是降低開發成本的關鍵,也是提升開發人員滿意度的基石。第二版以第一版的骨架為基礎,主要新增三個章節,分別延伸探討可維護性、Bounded Context、以元件為基礎的架構等第一版沒有深入探索的主題,為各位讀者補強「打造可維護軟體」所需的知識和技巧。
我們首先從傳統的階層式架構設計入手,針對此架構的優缺點開始討論。接著,我們也會討論由Robert C. Martin(Uncle Bob)所提出的「整潔的架構」(Clean Architecture)以及由Alistair Cockburn所提出的「六角形架構」(Hexagonal Architecture),探討這類以業務領域為主的架構設計有什麼好處。隨後,本書會用實際的Java和Kotlin程式碼,帶領各位讀者親自動手做一遍六角形架構的實作流程。你將學習如何在六角形架構的架構層之間選擇並實作對應策略,以及如何將架構中的各種元素組裝為應用程式。然後,我們也會說明如何強化架構中的邊界,並以理性的態度探討偷吃步的做法會造成什麼樣的技術債影響,以及在什麼樣的情況下,我們會願意承擔這類技術債。
讀完這本書,讀者將學會使用六角形架構的設計風格,建立整潔、可維護又經得起時間考驗的網頁應用程式。
學習目標:
・採用階層式架構會有什麼潛在問題
・如何強化架構中的邊界
・偷吃步做法會為軟體架構帶來什麼潛在影響
・應該在何時採用何種架構設計風格
・根據架構設計來安排程式檔案結構
・針對架構中不同的元素安排不同的測試策略
【下載範例程式檔案】
讀者可以從GitHub下載本書的範例程式碼,如果程式碼有更新,作者也會直接更新在儲存庫上:https://github.com/thombergs/buckpal
【下載本書的彩色圖片】
本書使用的彩色截圖和圖表,可以在此下載PDF檔案:https://packt.link/eBKMn
作者簡介
《無瑕的程式碼──整潔的軟體設計與架構篇》
Get Your Hands Dirty on Clean Architecture
Robert C. Martin
人稱Uncle Bob,程式設計經驗超過40年,Agile Software(敏捷軟體開發)的提倡者之一。
創立Object Mentor,這是一間專注於C++、Java物件導向、模式、UML、敏捷方法學和極限程式設計的顧問諮詢公司。
在這些領域,作者撰寫了相當多的名著,並獲得有IT奧斯卡獎之稱──Jolt震撼年度大獎。
其中,最暢銷的是《Clean Code》(中文版為無瑕的程式碼),為Amazon該類別的暢銷榜首,也被國內公認為程式設計師必讀的一本書。
《Clean Architecture實作篇:在整潔的架構上弄髒你的手, 2/e》
Get Your Hands Dirty on Clean Architecture, 2/e
Tom Hombergs
Tom Hombergs是一位專業資深軟體工程師,投身於此行業已十多年,曾服務各大企業客戶,並曾參與各種不同的軟體開發專案。這些軟體開發專案大多數都是以Java程式語言的開發環境為主,Tom則是在其中扮演過開發工程師、架構設計師以及教練等角色。Tom認為教學相長,因此寫書的過程對自己來說也是一次很好的學習機會,尤其是能從自身經驗及過往參與的軟體專案來探討各項議題,希望能夠透過文字,為混亂不明的軟體開發領域帶來秩序與一線光明。除了寫書以外,他也會在個人部落格reflectoring.io上發表一些關於軟體開發的文章,並且偶爾會在各大論壇上發表演講。
目錄大綱
《無瑕的程式碼──整潔的軟體設計與架構篇》
Get Your Hands Dirty on Clean Architecture
Part I 簡介
Chapter 1 什麼是設計與結構
Chapter 2 兩種價值觀的故事
Part II 從基礎開始:程式設計範式
Chapter 3 範式概述
Chapter 4 結構化程式設計
Chapter 5 物件導向程式設計
Chapter 6 函數式程式設計
Part III 設計原則
Chapter 7 SRP:單一職責原則
Chapter 8 OCP:開放-封閉原則
Chapter 9 LSP:Liskov 替換原則
Chapter 10 ISP:介面隔離原則
Chapter 11 DIP:依賴反向原則
Part IV 元件原則
Chapter 12 元件
Chapter 13 元件內聚性
Chapter 14 元件耦合性
Part V 架構
Chapter 15 什麼是架構
Chapter 16 獨立性
Chapter 17 邊界:畫線
Chapter 18 邊界剖析
Chapter 19 策略和層級
Chapter 20 業務規則
Chapter 21 會尖叫的架構
Chapter 22 整潔的架構
Chapter 23 Presenter 與Humble Object
Chapter 24 部分邊界
Chapter 25 層與邊界
Chapter 26 主元件
Chapter 27 服務:偉大與微小
Chapter 28 測試邊界
Chapter 29 整潔的嵌入式架構
Part VI 細節
Chapter 30 資料庫是細節
Chapter 31 Web是細節
Chapter 32 框架是細節
Chapter 33 案例研究:影片販售
Chapter 34 遺漏的章節
Part VII 附錄
Appendix A 架構考古學
《Clean Architecture實作篇:在整潔的架構上弄髒你的手, 2/e》
Get Your Hands Dirty on Clean Architecture, 2/e
二版推薦序|Teddy Chen
一版推薦序|Teddy Chen
譯者審校序|錢亞宏
推薦序|Gernot Starke
貢獻者
作者簡介
檢閱者簡介
作者序
本書目標
目標讀者
範例應用程式
下載彩色圖片
讀者回饋
讀者評論
Chapter 01:可維護性
可維護性是什麼意思?
可維護性能夠實現功能性
可維護性帶來開發者樂趣
可維護性能支援做出決策
維護可維護性
Chapter 02:階層式架構的問題點
資料庫驅動設計
在階層中偷吃步
難以執行的測試
使用案例不知影
平行分工的困難
如何讓軟體邁向可維護性的目標?
Chapter 03:依賴反轉
單一職責原則
與副作用之間的陳年往事
依賴反轉原則
整潔的架構
六角形架構
如何讓軟體邁向可維護性的目標?
Chapter 04:程式結構
以架構層為結構
以功能為結構
可呈現出架構的套件結構
依賴注入的影響
如何讓軟體邁向可維護性的目標?
Chapter 05:使用案例實作
領域模型實作
使用案例長話短說
輸入驗證
利用建構子的好處
不同的使用案例、不同的輸入模型
業務規則驗證
豐富領域模型與貧血領域模型
不同的使用案例、不同的輸出模型
唯讀使用案例的問題
如何讓軟體邁向可維護性的目標?
Chapter 06:網頁層轉接器實作
依賴反轉
網頁層轉接器的職責
分割開來的控制器
如何讓軟體邁向可維護性的目標?
Chapter 07:儲存層轉接器實作
依賴反轉
儲存層轉接器的職責
分割開來的轉接埠介面
分割開來的儲存層轉接器
以Spring Data JPA為例
資料庫交易的問題
如何讓軟體邁向可維護性的目標?
Chapter 08:架構測試
測試金字塔
領域實體的單元測試
使用案例的單元測試
網頁層轉接器的整合測試
儲存層轉接器的整合測試
系統主要路徑的系統測試
要多少測試才算夠?
如何讓軟體邁向可維護性的目標?
Chapter 09:架構層之間的對應策略
不對應策略(No Mapping)
雙向對應策略(Two-Way Mapping)
全部對應策略(Full Mapping)
單向對應策略(One-Way Mapping)
如何選擇要採用的策略?
如何讓軟體邁向可維護性的目標?
Chapter 10:應用程式組裝
組裝是有什麼好談的?
透過純程式碼組裝
透過Spring的類別路徑掃描功能來組裝
透過Spring的Java Config來組裝
如何讓軟體邁向可維護性的目標?
Chapter 11:理性看待偷吃步
偷吃步的破窗效應
第一步的重要性
在使用案例之間共用模型
把領域實體當成輸出或輸入模型
省略輸入轉接埠
省略服務
如何讓軟體邁向可維護性的目標?
Chapter 12:強化架構中的邊界
邊界與依賴關係
存取修飾子
編譯後檢查
建置成品
如何讓軟體邁向可維護性的目標?
Chapter 13:管理多個Bounded Context
為每個Bounded Context建立一個六角形?
解耦合的Bounded Context
適當耦合的Bounded Context
如何讓軟體邁向可維護性的目標?
Chapter 14:以元件為基礎的軟體架構方法
透過元件進行模組化
案例研究:打造一個檢查引擎元件
強化元件的邊界
如何讓軟體邁向可維護性的目標?
Chapter 15:選擇你的架構風格
從簡單開始
領域的發展
相信自己的經驗
視情況而定