這篇的開始就回顧一下，鐵人賽第一天文章的結論：

微服務不是終點，它只是一種手段。更重要的，是我們是否真正理解了背後的設計原則，以及它對組織、技術、團隊的深遠影響。

這就是我希望透過這個系列，和大家一起思考與討論的起點。

這個系列可以分成幾個部分：

(1) 微服務基本介紹：從基本概念到為什麼需要微服務

(2) 微服務架構模式：應用程式、應用程式基礎架構、基礎架構等透過大篇幅的介紹點出微服務的問題以及目前記載有案的解決方案有哪些

(3) 微服務的移轉：我認為微服務都是從既有系統演化來的居多，所以這部分特別重要 (當然有未完待續的，當作看電影的彩蛋)

這系列文章，就是先問問自己所面對的問題，希望這裡就可以讓你找到不做微服務的理由。（我看過太多不充分的理由，只是因為這是專案的限制所以要做微服務。現在可能是專案的限制所以要做 AI。）

如果你要面對微服務，就把「微服務架構模式」掃過一次，先預知自己未來可能遭遇的問題，以及記得這裡有答案。(至少有關鍵字好了！讓你在用 ChatGpt 或是 Google 的時候多一點準確率)！

再來，就是「單體式系統到微服務」，如果你真的要做微服務，不妨到天瓏書局搜尋這個關鍵字，帶回家！我想對你未來是具有趨吉避凶的效果。

為什麼寫這一個系列！

我自己本身對於軟體開發及軟體架構算是相當有興趣，所以一路以來涉略不少軟體架構的知識，在業界也好一段時間累積不少的經驗，也陸續地幫客戶做架構的設計與規劃。

我在業界通常是乙方的角色，簡單來說就是接專案，人家稱 SI 可能不是一個很好的工作內容，不過看到各式各樣的系統問題與架構解決方案，我覺得有趣。

很多時候，因為一些「流行」的原因，一瞬間會有很多類似的案子 (微服務、數據中台、業務中台 .... 當然現在還有 AI 好了)，我發現很多人對於自己為什麼要選這個架構沒有一個核心的思考，例如：為什麼你們要用 Clean Architecture ？

某業界的前輩說:我過去幾年曾問過想推廣 clean architecture 的成員：「你們為什麼需要用 clean architecture, 主要想解決什麼問題？」
我得到過的其中一個答案：「因為 Uncle Bob 說的。」

但是，實際上你透過這樣的技術更迭獲得什麼商業上的利益？

用架構模式涵蓋大部分章節，最主要的一個目的是「理解你的問題」然後選擇對的「解決方案」。

作為一個專業的「軟體工程師」，我們要的是替「商業問題」找到其對應的「技術解決方案」。

而不是用技術的解決方案製造「商業問題」！

以前同事戲謔地跟我說過：

工程師養蟲 (Bug)，蟲也回過來滋潤工程師！ 有 Bug 才有錢賺！

這或許也是我們這一行的生存之道，不過我自己還是覺得秉持著專業主義，雖然還是會有 Bug 啦！
畢竟沒有人可以全知全能，但多努力一點，問題就會少一點。

完賽心得

之前我也會鼓勵同事去把自己的學習成果寫下來發表，不過做的人不多就是了！

我自己是筆記狂吧！上班開會或是開發沒有筆記腦袋就轉不動，所以素材應該是有！

一開始我手邊很多零散的東西，但要串成一個系統又很花時間整理，剛好近年一直在討論這個議題，也蒐集很多客戶執行的狀況，所以就用這個當主題。

計劃趕不上變化

一開始我有規劃一個章節順序，最後寫著寫著好像針對某些篇幅開始「意見太多」寫得太長，時間花太多不得不做個段落。

原本以為，自己寫的篇幅會很少，都是極短的短文，但沒想到寫下去之後一直補充一直補充，所以中間就只好改變相關的計劃。

先完成再說

基本上我都有先準備好草稿，然後要上發佈前再來改一下，但某些日子就突然要開會，突然加個班，突然去一下社群。每當這些日子，只好讓草稿先上線了，然後再來修改。

先完成，再完善！

開始前，我問了一下有參賽的前輩，你的文章都是每天現打的嗎？ (得到答案後，我就先用一週時間整理一下內容，有一些概念跟存底後開賽)。

又完成了自我的一項挑戰

下次我可以更理直氣壯地跟同事討論要發表自己所學，寫就是一種「思考」，當然遇到有人提問自己也會有反思。
(有時候我在回答客戶或是同事問題的時候，念著念著也會突然間有新的靈感，隨著邏輯的思路而產生)。

我連續 30 天寫 markdown

本來是不熟悉 markdown，透過 30 天的練習，應該已經變成自己的一個技能。現在用 AI 開發的時候，Markdown 好像也是一個好工具。

你分享出來不怕技能被偷走

基本上，我們這行秘密也不太多，這些東西真想學其實買了幾本書大概就可以窺知一二。所以，想學的我也攔不住，我沒分享他也會學會，不想學的看了也不會深入探討，所以應該沒差。

再者，這些很多都是一個概念，你還要花時間練習真正的實作，還要有那個場域那麼複雜的系統淬鍊這些技能，這要偷可以很簡單也可以很難。

基本上，這些分享的資訊都是從幾本書上整理下來且我實際在工作上使用的部分，底下提供相關資料來源：
• Microservice Architecture Pattern（Chris Richardson 整理的模式彙編）
• Building Microservices（Sam Newman 經典著作）
• Monolith to Microservices（Sam Newman 對遷移的深度分析）
• Domain-Driven Design Distilled（Vaughn Vernon 關於 DDD 的精簡版）
• 領域驅動設計工作坊（實務上的工作坊經驗，包含事件風暴、上下文界線討論）

或許你會覺得有些概念似曾相似，代表我們看過相同的書籍。希望這些內容不只是書本理論，而是能夠讓我們在日常工作中拿來檢驗、拿來設計、拿來反思的「知識地圖」。