Spring Pet Clinic 是由Spring團隊成員撰寫的範例程式，其中展示Spring的使用方式；它從2007年就開始發展，期間中斷了數次，直到2016年由Spring Boot/Spring Cloud 的重要貢獻者 Dr. Syer重新開始撰寫至今。 我打算以Spring Pet Clinic Microservice做為基礎，並從測試的角度來一系列解析這個範例程式，除了從中學習Spring Boot、Spring Cloud，並理解Microservices相關架構設計與開發。雖然其中不見得包含領域驅動設計、六角形或Clean Architecture，但絕對是學習Spring 的好教材。 這系列的第一篇，首先我們來看看它的部署與使用方式。可以從這個網址(https://github.com/spring-petclinic/spring-petclinic-microservices)下載程式碼，由於現在的Spring Pet Clinic 已經用Spring Boot 3改寫，請在執行前確定電腦是否已經安裝 JDK17。

最近實在有點忙亂，一直找不到時間可以完整的寫下我在DDD Taiwan Conf 2020談的內容，趁著睡不著的晚上，簡單寫下我談的內容。 關於我 寫過GPS與光碟機韌體 參加過幾個專案：電子採購系統、電子商務系統、支付系統、網路銀行 扮演過程式設計師、分析師、架構師、PM等角色 2. 什麼是設計 紮實的軟體工程比耍花槍重要 設計沒有標準答案，不是：百王之無變 …

最近有點忙亂，有段時間沒有寫新的文章，今天紀錄一下顛覆的程式編寫順序。 補充說明: [2020/12/05] 這個方法在Uncle Bob的著作-Agile Principles, Patterns and Practices in C#裡有提到，叫做基於意圖的程式設計(intentional programming) 在Clean Coder 裡面 Uncle Bob提到自己向Kent Beck學習TDD的情況，也啟發Uncle Bob設計了一些練習TDD的Kata。Uncle Bob在書中提到，他跟Kent Beck進行 Pair Programming，Kent Beck先思考尚未編寫的class與method要怎麼使用，把使用方式或是API的組合方式，寫在Test Case裡，每當發現缺少什麼Production Code，就編寫足以通過測試的Production Code，然後就回到Test Code繼續組合他想要的API，如此不斷往返，慢慢的Production Code完成。

最近因為某些因素，我重讀了Uncle Bob 的 Clean Architecture，找尋解決問題的靈感。大師的書裡總是有微言大義，也許是我的理解力太差，哈。 何謂架構？為什麼需要架構設計？ 我對於軟體架構設計的興趣，來自於歷經幾個慘烈的專案後，我開始思考有沒有什麼方式可以讓專案進行得順利一些？系統維護與變更也可以更容易一些？因為長年開發工作的關係，很多機會跟客戶、同事討論到系統設計，總是著重在”如何在時程與預算內完成需求”；敏捷是我其他戰友走的一條路，架構設計則是我覺得可行的另一條路，也成為我這幾年來尋尋覓覓的方向。敏捷當然也要有架構設計，但不是每個人都這樣想，不過，那又是另外一個故事了。 Uncle Bob 在書中定義了軟體架構的目標：軟體架構的目標是最小化建置和維護「需求系統」所需要的人力資源。 以我個人世俗的說法就是，如何以最快的速度、最少的人力與經費負擔完成專案(全新或是需求變更都算)，大家可以平安回家，就是軟體架構的目標XD。但通常，我們在有限的時間、資源與人力情況下，僅僅只能想到如何按照規劃準時上線，甚至品質與預算都沒辦法被詳細評估，甚至犧牲，更不可能想到，未來如何發展這個滾燙的山芋。

這篇來聊聊我參與支付系統的設計經驗，也反思，如果在未來如果還有機會，我應該要做什麼準備？會怎麼做？下面所提到的系統，已經停用被其他新系統所取代，我將不會把系統的細節與專有名詞直接暴露，避免爭議。 前情提要 過去曾經以乙方的身份，參與多項系統開發與維運，其中包括電子採購系統、CRM、eCommerce與支付系統。每個系統都讓我有許多不同的收穫，其中支付系統是一個龐大、複雜且營運時間超過十二年的系統。支付系統開發廠商也就是我的前雇主，在系統上線後留下團隊，持續協助甲方後續的維運與系統增修工作；我是在系統上線八年後，才參與兩年多的系統分析與設計工作。系統開發初期是由上百位Developer參與，在系統完成後，僅留下五位Developer與三位分析師持續接受客戶需求變更。團隊中的五位Developer對整個系統的掌握度極高，流動的分析師們相當依賴他們，畢竟沒有任何一位分析師待得比他們久。多年來，需求變更不斷，使用情境越來越複雜，所以沒有太多時間可以重新思考架構。

在多本書籍闡述測試驅動開發(Test Driven Development，TDD)的好處之後，我又回頭看了Uncle Bob的保齡球套路，深信這個套路就如同武術家練習的拳譜、運動選手的基本動作，或是軍警不斷練習的拔槍與演習動作。那就讓我來整理一下這個套路的準備工作與相關細節吧。 保齡球套路中，須先理解保齡球的規則，說明如下： 一場保齡球共有十局( …

從語言之爭到框架之爭 最近或應該說時常看到網路上有人提到：新出來的xx 語言海放了 oo語言，不意外的就會有人開始贊(ㄍㄠ)同(ㄔㄠˊ)，然後就有人會出來為oo語言辯護，但事實上xx語言的擁戴者並沒有看到oo語言背後的生態與多年以來發展的工具、框架等，那才是這個使用多年oo語言的價值所在。另外，要說的是Spring Framework發展多年來，也搭上雲原生的熱潮，推出了易於開發微服務的 Spring Boo與 Spring Cloud；而另一支號稱真正基於雲原生需求的開發框架 Quarkus，也開始蓬勃發展且來勢洶洶。但是，其實我更關心的是我怎麼解決手上的問題，完成任務，讓團隊可以平安的回(ㄊㄨㄛ)家(ㄕㄣ)，所以，更想知道如何正確且有效率的滿足不斷改變的需求。也許，我們還真的聽聽某電信公司的廣告詞：世界變化越快，而我們的心則要越靜(OS：明明就是你們自己的網路太慢，要大家等XD)。 回顧過去

多年以來，參與過幾個軟體專案，歷練過程式設計師、系統分析師、系統架構師，甚至專案經理。這段時間以來，系統設計與開發多以OOAD與之前的經驗為依據，雖然沒有什麼大問題，但也總覺得沒有太多系統性的思考與規劃，甚至以不同角度規劃的系統，會出現矛盾的情況，只好折衷與取捨之後，才能往下，更別說時常會糾結在使用什麼前端技術、框架與資料庫等。 簡稱 DDD的領域驅動設計(Domain Driven Design)提供了許多的建模建議，與簡潔架構(Clean Architecture) 闡述了如何讓軟體架構層次分明、更易於維護與發展，引起我莫大的興趣；雖然看過一些書籍、聽過一些演講與自己公司相關文件，但沒有機會推展到實作階段，總有些隔靴搔癢與遺珠之憾。Pivotal 有一群具有實戰經驗的服務團隊，無奈我尚未等到他們來到台灣服務客戶。 泰迪軟體一直在這些主題有許多的闡述與課程，這次終於有時間可以參加，實在幸運，也重新審視自己已知或是誤認的知識。趁著這次課程結束與工作調整的機會，正好可以再次閱讀相關書籍，找幾個過去參與過的專案進行驗證實作，並寫下心得筆記，當作迎接未來挑戰的準備。期待在這一連串的驗證過程，除了前述的兩個方法論納入，也將設計模式、無暇的程式碼與設計驅動開發等加入，讓過去看起來片段的知識，更加有連貫性。