今天早上將golang的三個service推到各自的git repo後，想到了一些問題，而其中最讓我在意的是各自的repo的必要性。從microservice的角度來看，每個service都是一個獨立的專案，這本來也沒有什麼問題，以一個專案放到一個git repo的方式是正常的。然而，這之間有些有趣的結構上的問題。首先就是跨service會用到的相依性，再來就是為了要執行所有service而使用的docker-compose。

當各自的service是放在自行的git repo裡

• Service A
• Service B
• Service C

這時有多個service都會用到的相依性

• Dependency 1

在使用時，一個想法是將Dependency 1當作sub module放到servcie下

• Service A
  • Dependency 1
• Service B
  • Dependency 1
• Service C
  • Dependency 1

這時加上了docker compose的設定資料，因為要一起啓動，肯定不會再弄一個repo以sub module的方式進入到不同的service裡，反而比較像是每個service以sub module的方式進入到這個含有docker compose設定的repo裡。

• Config Repo
  • Service A
    • Dependency 1
  • Service B
    • Dependency 1
  • Service C
    • Dependency 1

光從這樣單純的結構裡就看到了二層的git sub module，若是行為更加的複雜時，會不會讓sub module層次變得更深更複雜？

在nodejs的開發演進中，從原先的mono架構轉變成micro service加構，並用單一的git repo去裝填不同的micro service。但這些年又調整成依然是microservice的架構，但轉回成monorepo的放置形態。或許golang寫出的service也可以師法這樣的概念，在這樣的想法縈繞之下，快速的查了google，找到了很接近現在想法的調整方式

• Full-stack monorepo - Part I: Go services

Side Note

好奇除了go.mod要進git repo外，go.sum要不要進去git repo？找到了這份文件，至少知道go.sum也是要進到git repo的

• Releasing Modules (All Versions)

Focus on Making Project

今天的時間主要都是在處理專案的調整，不論是前端也好，後端也好。只要不好好的調整，一下子就變得很亂，不方便之後的開發。再加上還要花時間了解後端改成了monorepo後要怎麼樣和跨前後端的資料做接合。整個時間就只能投在調整上，沒有太多的時間更新和記錄。