Mono-repo 單一管理架構

• 所有的套件、函式庫或是子專案都在同一個版本控制的 Repo 中。
• 每個套件或是子專案都在倉庫的不同子目錄中，這些子目錄各自獨立，但都共用同一個父目錄。
• 這些子專案都共享同一個設定檔、工具、腳本等等，因此發布週期、流程一致。
• 因為在同一個 Repo 中，所以可以統一做版本控制。

Multi-repo (Polyrepo) 分散管理架構

• 將每個子專案都分別存放在不同版本控制的 Repo 中。
• 個別專案有獨自的相依性管理、版本控制、開發流程及發布週期。
• 專案之間的相依性使用套件管理工具來處理，通過版本號引用其他專案或套件。
• 這個架構適合獨立性比較強，發布週期不同的專案。

Microservices Architecture 微服務管理架構

• 拆分成多個小型的、獨立的服務，每個服務都有自己的程式碼部署及擴展能力，啟動速度快，技術多樣化。
• 通常圍繞功能或不同業務能力進行組織，通常使用 API 進行相互傳接。
• 這個專案架構適合複雜且不斷演進的專案架構，他具有相當大的彈性和擴展性。
• 缺點也十分明顯，部署、資料一致性管理困難。

Modular Monolith 模組化單體管理架構

• 模組化單體架構，在 Monorepo 跟 Polyrepo 之間的折衷方案，他將應用程式規劃成多個獨立模組，但仍然部署單一個應用程式。
• 模組化單體模式提供了一定的解耦性，同時又避免像是微服務架構上管理的複雜性，模組之間互動效率較高。
• 模組之間的相依性比較強，要擴展仍然會需要考慮整體應用程式。

Plugin Architecture 外掛管理架構

• 外掛架構管理分成一個核心系統以及多個外掛模組，透過核心系統基本的功能和擴展點，與外掛模組進行互動跟擴展。
• 適合需要高度自定義的應用程式，比方說瀏覽器、編輯器或是開發工具，這可以促成第三方開發者的參與。

Layered Architecture 分層管理架構

• 分層管理架構管理，分為多個層次，每個層次都有既定的職責，各層的關注焦點分離，可以使系統更好去維護。
• 通常分為表層（Presentation Layer，通常是使用者介面）業務邏輯層、資料存取層。
• 每個層級都有明確獨有的職責，每個層次只與相鄰的層次進行互動，透過這些明確的定義進行互動。
• 分層架構容易過於緊密，容易影響整個系統的彈性。