閒談軟體設計
40免費公開
這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。
本文探討後端 API 安全驗證機制，說明如何基於請求憑證進行身家調查，確保只有授權使用者才能存取資源。文中詳細闡述了資料採信原則、角色來源、組織層級的設計考量，並介紹簡單的實作範例，以確保系統安全。
本文探討後端 API 安全驗證機制，說明如何基於請求憑證進行身家調查，確保只有授權使用者才能存取資源。文中詳細闡述了資料採信原則、角色來源、組織層級的設計考量，並介紹簡單的實作範例，以確保系統安全。
本文探討如何使用函數式風格聲明 Javalin API endpoint 的安全性需求，並透過組合函數，例如 any 和 all，以及自定義函數，例如 anyManager 和 anyOwner，來簡化複雜的權限檢查。此方法避免了使用註解的繁瑣，並提高了程式碼的可讀性和可維護性。
本文探討如何使用函數式風格聲明 Javalin API endpoint 的安全性需求，並透過組合函數，例如 any 和 all，以及自定義函數，例如 anyManager 和 anyOwner，來簡化複雜的權限檢查。此方法避免了使用註解的繁瑣，並提高了程式碼的可讀性和可維護性。
從Spring Boot轉換到Javalin的過程與考量，以及如何保持核心業務邏輯與Web框架的距離以提升專案彈性。文中比較了Micronaut, Helidon和Javalin三個輕量級框架，並說明選擇Javalin的原因及優缺點。
從Spring Boot轉換到Javalin的過程與考量，以及如何保持核心業務邏輯與Web框架的距離以提升專案彈性。文中比較了Micronaut, Helidon和Javalin三個輕量級框架，並說明選擇Javalin的原因及優缺點。
日誌設計包含幾個重要考量因素，包括關聯式查詢、雲端生態支援、情境豐富性、結構化日誌以及與商業邏輯核心保持距離。利用 correlation ID、ThreadLocal 以及自定義抽象物件，實現了這些需求，並簡潔地說明在不同任務發動情況下 (API請求、定時執行、事件驅動) 的使用
日誌設計包含幾個重要考量因素，包括關聯式查詢、雲端生態支援、情境豐富性、結構化日誌以及與商業邏輯核心保持距離。利用 correlation ID、ThreadLocal 以及自定義抽象物件，實現了這些需求，並簡潔地說明在不同任務發動情況下 (API請求、定時執行、事件驅動) 的使用
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
這是幾年來我對於軟體架構師的心路歷程，上述不保證讓你成為軟體架構師，但希望會對軟體工程師職涯有幫助。也希望台灣的軟體公司能稍微多注重一下軟體架構，甚至能像 91App 不只工程師團隊，還有軟體架構團隊。
這是幾年來我對於軟體架構師的心路歷程，上述不保證讓你成為軟體架構師，但希望會對軟體工程師職涯有幫助。也希望台灣的軟體公司能稍微多注重一下軟體架構，甚至能像 91App 不只工程師團隊，還有軟體架構團隊。
我覺得好的體驗，大多不需要 production code 有對應的修改或調整，主要來自工具的優化，像是 IDE、CI/CD 等。但接下來討論的體驗，須對 production code 進行修改，甚至影響到撰寫，但帶來的體驗我覺得是有待商榷的。
我覺得好的體驗，大多不需要 production code 有對應的修改或調整，主要來自工具的優化，像是 IDE、CI/CD 等。但接下來討論的體驗，須對 production code 進行修改，甚至影響到撰寫，但帶來的體驗我覺得是有待商榷的。
我個人是盡可能不寫 switch statement，但觀察這幾年程式語言的趨勢，會發現許多語言把 switch statement 擴充成為實作 pattern matching 的工具，說不定以後 switch statement 會越來越廣泛使用也說不定。
我個人是盡可能不寫 switch statement，但觀察這幾年程式語言的趨勢，會發現許多語言把 switch statement 擴充成為實作 pattern matching 的工具，說不定以後 switch statement 會越來越廣泛使用也說不定。
長遠的角度來看，內部函式庫還是值得投資的公司資產，只是它需要時間、人力與管理才能做得好。若有不錯的內部函式庫也可以回饋給open-source社群，畢竟，現在開發軟體已經不太可能沒有用到任何open-source的東西。雖然說是將公司資產以 open-source 釋出，但換取的利益卻不見得是零。
長遠的角度來看，內部函式庫還是值得投資的公司資產，只是它需要時間、人力與管理才能做得好。若有不錯的內部函式庫也可以回饋給open-source社群，畢竟，現在開發軟體已經不太可能沒有用到任何open-source的東西。雖然說是將公司資產以 open-source 釋出，但換取的利益卻不見得是零。
整結來說，受到幾種語言的影響，我個人設計 API 時，除了合乎該語言的 convention、上述的穩定性及一致性外，大致還會注意幾點：語意清楚、相近的顆粒度、簡單的文件、讓程式能像文章般閱讀。
整結來說，受到幾種語言的影響，我個人設計 API 時，除了合乎該語言的 convention、上述的穩定性及一致性外，大致還會注意幾點：語意清楚、相近的顆粒度、簡單的文件、讓程式能像文章般閱讀。
第三方套件用了Promise或是Reactive，導致所有business logic都要做調整，這就違反「只能有對內的相依方向」的原則。business logic大多數情況下與效能優化無關，通常需要優化的是I/O的存取，這些既然都在外層，就應該在外層做優化，外層的優化不該影響核心，這才是好架構。
第三方套件用了Promise或是Reactive，導致所有business logic都要做調整，這就違反「只能有對內的相依方向」的原則。business logic大多數情況下與效能優化無關，通常需要優化的是I/O的存取，這些既然都在外層，就應該在外層做優化，外層的優化不該影響核心，這才是好架構。
本文探討後端 API 安全驗證機制，說明如何基於請求憑證進行身家調查，確保只有授權使用者才能存取資源。文中詳細闡述了資料採信原則、角色來源、組織層級的設計考量，並介紹簡單的實作範例，以確保系統安全。
本文探討後端 API 安全驗證機制，說明如何基於請求憑證進行身家調查，確保只有授權使用者才能存取資源。文中詳細闡述了資料採信原則、角色來源、組織層級的設計考量，並介紹簡單的實作範例，以確保系統安全。
本文探討如何使用函數式風格聲明 Javalin API endpoint 的安全性需求，並透過組合函數，例如 any 和 all，以及自定義函數，例如 anyManager 和 anyOwner，來簡化複雜的權限檢查。此方法避免了使用註解的繁瑣，並提高了程式碼的可讀性和可維護性。
本文探討如何使用函數式風格聲明 Javalin API endpoint 的安全性需求，並透過組合函數，例如 any 和 all，以及自定義函數，例如 anyManager 和 anyOwner，來簡化複雜的權限檢查。此方法避免了使用註解的繁瑣，並提高了程式碼的可讀性和可維護性。
從Spring Boot轉換到Javalin的過程與考量，以及如何保持核心業務邏輯與Web框架的距離以提升專案彈性。文中比較了Micronaut, Helidon和Javalin三個輕量級框架，並說明選擇Javalin的原因及優缺點。
從Spring Boot轉換到Javalin的過程與考量，以及如何保持核心業務邏輯與Web框架的距離以提升專案彈性。文中比較了Micronaut, Helidon和Javalin三個輕量級框架，並說明選擇Javalin的原因及優缺點。
日誌設計包含幾個重要考量因素，包括關聯式查詢、雲端生態支援、情境豐富性、結構化日誌以及與商業邏輯核心保持距離。利用 correlation ID、ThreadLocal 以及自定義抽象物件，實現了這些需求，並簡潔地說明在不同任務發動情況下 (API請求、定時執行、事件驅動) 的使用
日誌設計包含幾個重要考量因素，包括關聯式查詢、雲端生態支援、情境豐富性、結構化日誌以及與商業邏輯核心保持距離。利用 correlation ID、ThreadLocal 以及自定義抽象物件，實現了這些需求，並簡潔地說明在不同任務發動情況下 (API請求、定時執行、事件驅動) 的使用
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
這是幾年來我對於軟體架構師的心路歷程，上述不保證讓你成為軟體架構師，但希望會對軟體工程師職涯有幫助。也希望台灣的軟體公司能稍微多注重一下軟體架構，甚至能像 91App 不只工程師團隊，還有軟體架構團隊。
這是幾年來我對於軟體架構師的心路歷程，上述不保證讓你成為軟體架構師，但希望會對軟體工程師職涯有幫助。也希望台灣的軟體公司能稍微多注重一下軟體架構，甚至能像 91App 不只工程師團隊，還有軟體架構團隊。
我覺得好的體驗，大多不需要 production code 有對應的修改或調整，主要來自工具的優化，像是 IDE、CI/CD 等。但接下來討論的體驗，須對 production code 進行修改，甚至影響到撰寫，但帶來的體驗我覺得是有待商榷的。
我覺得好的體驗，大多不需要 production code 有對應的修改或調整，主要來自工具的優化，像是 IDE、CI/CD 等。但接下來討論的體驗，須對 production code 進行修改，甚至影響到撰寫，但帶來的體驗我覺得是有待商榷的。
我個人是盡可能不寫 switch statement，但觀察這幾年程式語言的趨勢，會發現許多語言把 switch statement 擴充成為實作 pattern matching 的工具，說不定以後 switch statement 會越來越廣泛使用也說不定。
我個人是盡可能不寫 switch statement，但觀察這幾年程式語言的趨勢，會發現許多語言把 switch statement 擴充成為實作 pattern matching 的工具，說不定以後 switch statement 會越來越廣泛使用也說不定。
長遠的角度來看，內部函式庫還是值得投資的公司資產，只是它需要時間、人力與管理才能做得好。若有不錯的內部函式庫也可以回饋給open-source社群，畢竟，現在開發軟體已經不太可能沒有用到任何open-source的東西。雖然說是將公司資產以 open-source 釋出，但換取的利益卻不見得是零。
長遠的角度來看，內部函式庫還是值得投資的公司資產，只是它需要時間、人力與管理才能做得好。若有不錯的內部函式庫也可以回饋給open-source社群，畢竟，現在開發軟體已經不太可能沒有用到任何open-source的東西。雖然說是將公司資產以 open-source 釋出，但換取的利益卻不見得是零。
整結來說，受到幾種語言的影響，我個人設計 API 時，除了合乎該語言的 convention、上述的穩定性及一致性外，大致還會注意幾點：語意清楚、相近的顆粒度、簡單的文件、讓程式能像文章般閱讀。
整結來說，受到幾種語言的影響，我個人設計 API 時，除了合乎該語言的 convention、上述的穩定性及一致性外，大致還會注意幾點：語意清楚、相近的顆粒度、簡單的文件、讓程式能像文章般閱讀。
第三方套件用了Promise或是Reactive，導致所有business logic都要做調整，這就違反「只能有對內的相依方向」的原則。business logic大多數情況下與效能優化無關，通常需要優化的是I/O的存取，這些既然都在外層，就應該在外層做優化，外層的優化不該影響核心，這才是好架構。
第三方套件用了Promise或是Reactive，導致所有business logic都要做調整，這就違反「只能有對內的相依方向」的原則。business logic大多數情況下與效能優化無關，通常需要優化的是I/O的存取，這些既然都在外層，就應該在外層做優化，外層的優化不該影響核心，這才是好架構。