Agenda ■ 敏捷一詞，幾乎成為軟體開發領域的罩門 ■ 敏捷？是解藥還是毒藥？其實敏捷是有門檻的！ ■ 您的軟體架構設計好了？ ■ 軟體架構不是設計出來的 ■ 軟體『架構設計』與『成本』的關係 ■ 常見的軟體設計架構指南 ■ Clean Architecture 插件式軟體架構 ■ 從 Clean Architecture 來探討什麼是敏捷的軟體架構？ ■ 從使用者需求、談架構設計 ■ 在 Clean Architecture 裡的 ATDD／TDD？ ■ 一個敏捷的軟體架構 ■ 在軟體技術市場、需求、市場多變現代你是否覺得疲於奔命？ ■ 技術變成速食？ 但是沒有辦法被 資源回收再利用～該怎麼辦？

1. Gelis 程式設計訓練營
軟體開發之路

2. 吳俊毅 Gelis - FB 軟體開發之路-經營者
關於我
• 部落格 (Gelis 技術隨筆)
http://gelis-dotnet.blogspot.tw/
• FB 粉絲團(Gelis 的程式設計訓練營)
https://www.facebook.com/gelis.dev.learning/?ref=bookmarks
• FB 社團 (軟體開發之路)
https://www.facebook.com/groups/361804473860062/?ref=ts&fref=ts
集英信誠-資深.NET技術顧問

3. 關於我

4. 接觸Visual
Studio
2002、
WinForm
使用 VB6
做了校務
行政等幾
個專案、
接觸
Delphi 3.0
接觸
Delphi 2.0
實際在專案實作中
使用
ASP.NET、.NET
Remoting、
Web Service
撰寫一本
書 Delphi
2005 .NET
程式設計
人生、
工作、
轉淚點
加入緯創
軟體並選
上
Microsoft
MVP
轉加入集
英信誠
開始顧問
身涯
集英信誠
與大師
對談
創立Gelis
程式設計
訓練營、
軟體開發
之路
現在
FB
軟體開發之路
（技術分享會）
籌備、發行
更多的
線上課程

6. 其實，今天是『開發』課程！！！

7. 敏捷

10. 0 缺陷的架構？
將所有功能均提供在軟體產品裡，也就是大雜燴的方式，
嘗試滿足市場各種不同的需求

11. 0 缺陷的架構？
將所有功能均提供在軟體產品裡，也就是大雜燴的方式，
嘗試滿足市場各種不同的需求
(1). 使用單一功能滿足所有企業的使用者難以永久滿足…
（因為總是會有需要客製的部分）
(2). 功能一定會微調、若為此開立分支（Version Control）將產生另一個災難
(3). 客戶一多，表示你的功能分支越多、這又會產生另一個災難
(4). 軟體架構因為為滿足 A 客戶的某 Function ==> 而導致 B 客戶另一個
Function 失敗
(5). 疊床架屋的軟體終究越來越龐大、每修正一個 Function 或是 擴增一個
Function 都會是一個耗時耗力的過程

14. 價值 (Value) 架構 (Architecture)

15. 不良的架構
因為升級替換成本非常巨大
甚至限制住公司的發展

17. • 可以開發出符合商業需求的軟體？
• 可以開發出為客戶創造價值的軟體？
• 可以開發出符合市場預期的產品？
• 其實軟體公司談敏捷，就是為了『獲利！』

20. 已經
就要了解所有的需求，
那豈不是代表要先確定
需求？

22. 已經

23. 已經

25. 週期（Cycle）、階段
（phase）、Iteration(迭代)
行
為（activities）、工作流（workflow）、產
品（artifact）、角色（worker）

27. Jeffrey Palermo

29. Business
Logic
INNER

31. 回歸到最原始的需求面…
你覺得，
你掌握住需求的大方向了嗎？
全貌

34. 其實、
敏捷是有門檻的！

35. 武學中”招式”往往最吸引人

36. 但萬法規宗…
『基礎』才是最重要的！！

37. Angular
CSS
DOM
JavaScript
AJAX/Asynchronous
HTML
HTTP
外圈才是重要
√
√
√
√
√
√GET
POST
PUT ...

42. organizations which design systems ... are constrained to produce
designs which are copies of the communication structures of these
organizations.
UML 創始人之一 Grady Booch：
演化 一部分架構的變
化不會對架構的其它部分產生不必要的負面影響
讓（應用
／功能 functional）的易變部分能夠頻繁地變化，
對 Non-Functional 的影響儘可能地縮小。

44. Interface

45. Unit Test
『插件式』軟體架構 - Clean Architecture

48. UI
Iteration
架構可經由迭代不斷演化
• Unit Test

49. 測試 (Unit Test)
• 傳統的瀑布式 Waterfall 為人所詬病的就是，當你確定完
需求、開始做設計，這時候，往往已經過度設計了...

50. 但沒有確定的（實作／未實作）

60. （CCP／REP）

63. 好維護 Refactor 符合客戶所需(價值)

64. By Donald Firesmith
https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html

69. 架構
擴張
擴張 擴張
擴張

70. 追不上
架構

72. ATDD
Acceptance Testing
共識
目標
期望
(1). Write
a failing
code
(2). Make
the Test
pass
(3).
Refactor
Domain Model
Clean Architecture
OOA/OOD
Validation
Verifies
TDD
Validate
Verification

74. Domain Service
Use Cases
Domain
Model
Service Layer
Gateways
UI
JSON Over (Web API/SignalR)
DB
ApiHostBase
IIS
Redis/Cache
Socket/ Tcp

75. • 會使用哪一種 UI？
• 會使用哪一種資料庫？
• 會運行在 Windows？還
是 Linux？
• 誰會存取我？Mobile？
Web？Any Devices…
• …
不知道
不知道
不知道
不知道

81. https://www.slideshare.net/GelisWu/code-
review-52137113

82. 延展
性
程式語言
專
案
開
發
易於被使用
(門檻低) 規範
經
驗
中
學
習
信
任
DevOps

83. 微服務的架構規劃
 微服務解決了 SOA 長久一來無法解決的問題
 微服務讓傳統企業組織內應用程式充分利用運算資源
 微服務做到真正的高可用性
 微服務做到最佳化資源使用率
 微服務做到降低應用程式與作業環境的依賴性
 故障隔離、服務不會因為其中一個服務掛掉而影響其他服務
 微服務達到應用程式或服務的快速佈署的目的
 自動化佈署 - DevOps 的最佳實踐

85. 演化 『測試』
【更新／部署】
自動化測試+完整的更新程序 自動化部署 監控系統
DevOps

86. • 你只要思考： 人為主／工具為本／技術為輔
圖片出處：https://cn.dreamstime.com/%E5%BA%93%E5%AD%98%E7%85%A7%E7%89%87-%E6%B1%BD%E8%BD%A6%E5%B7%A5%E5%85%B7%E7%AE%B1-image43896895

87. 94

89. Demo：
Project Template 成品演示
1. MyORM Framework
2. EasyArchitect UI

90. MyORM Framework
• EasyArchitect UI Framework

91. 3) 盡可能落實 Code-Review
Check-In Policy 定義 開發的守則 (共同規範)
goto (3) 循環
goto
(3) 循環