在 Hacker News Daily 上看到「MonolithFirst」這篇，是 Martin Fowler 在 2015 年寫的文章，對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的，可以一起翻。
tl;dr：他的文章就是在講新專案用 monolith，不要去碰 microservice。
文章開頭提到了就他觀察到的情況：第一點是，幾乎所有成功的 microservice 案例都是從 monolith 起頭，再轉到 microservice 環境；第二點是，幾乎所有一開始用 microservice 的案例，在後來都遇到嚴重的問題：
As I hear stories about teams using a microservices architecture, I've noticed a common pattern.
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up
- Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
文章接著有兩個猜測，試著去解釋為什麼。
第一點可能的原因是 Yagni (You Aren't Gonna Need It)，在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜，快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多，而且可以快速修改。
第二點分成兩個現象：第一個現象是，即使是對產品的商業領域很有經驗的資深架構師，也很難一開始就切出正確的 BoundedContext；第二個現象是，在 microservice 裡，改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。
文章接著想要提出一些建議，在一開始使用 monolith 可以注意的方向，這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。
第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式，當想要切換到 microservice 的時候就有機會比較簡單。
第二種是更常見的方式，一開始先是 monolith 架構，然後把 boundary 好切割的拆成 microservice，所以在過度期會是一組不那麼大的 sub-monolith 架構，然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。
第三種方式就是砍掉重練。
第四種方式是一開始的時候不用 monolith，而是幾個很大包的 service (所以一開始不太能叫 microservice)，當商業模式成熟穩定後，切出更細緻的 boundary 的時候再拆成 microservice。
把這篇文章拿去搜尋 Hacker News 上的討論，可以看到除了 2021 年的這次討論外，在 2017 年的時候就有一批討論也蠻有趣的，可以看到有些不同的風向：「Monolith First (2015) (martinfowler.com)」。
當然也未必要信 Martin Fowler 的看法，軟體工程這塊還是有很多不同的流派...