以下依序介紹十多種主流架構及其特性。
2.1 層次式（Layered）架構
定義： 系統按功能或責任分為多層（如表示層、業務層、資料存取層），高層呼叫低層提供服務Crowdbotics。
優點： 分離關注點、易於維護；適合小型團隊與傳統企業應用。
缺點： 須逐層傳遞，可能產生性能瓶頸；變更需同步調整多層。
適用場景： 需求相對穩定、團隊規模較小的企業資訊系統。
2.2 單體（Monolithic）架構
定義： 整個應用程式作為單一部署單元，包含UI、業務邏輯與資料存取，部署一次即完整IT新聞。
優點： 實作與部署簡單；初期開發速度快。
缺點： 隨系統壯大易成為「巨石」，維護與擴展困難；可用性受單點影響。
適用場景： MVP或早期專案，需快速驗證商業模式。
2.3 微服務（Microservices）架構
定義： 將系統拆分為多個獨立服務，可獨立開發、部署與擴展Wikipedia黑球开发。
優點： 高度鬆耦合、彈性擴展；各服務可使用最佳化技術棧。
缺點： 複雜度高，需額外考量服務間通訊、資料一致性與運維工具。
實務案例： Netflix由單體轉向微服務，透過Conductor等工具進行流程編排，實現千萬級用戶的彈性擴展與敏捷部署LinkedInWikipedia。
2.4 事件驅動（Event-Driven）架構
定義： 系統以事件流為核心，各模組透過發布/訂閱或中介者模式非同步互動Crowdbotics。
優點： 高度擴展性與可延展性；適合實時分析、物聯網等場景。
缺點： 調試與追蹤較困難；需處理事件順序與重播。
適用場景： 金融交易系統、即時監控與資料流處理。
2.5 無伺服器（Serverless）架構
定義： 開發者專注撰寫函式（Function），由雲端平台（如AWS Lambda、Azure Functions）自動管理運算資源MediumMedium。
優點： 無需維運伺服器；按使用量付費，降低閒置成本。
缺點： 冷啟動延遲；受限於平台規格與服務契約。
適用場景： 事件觸發型應用、批次作業、輕量API後端。
2.6 六角形（Hexagonal／Ports and Adapters）架構
定義： 將核心業務邏輯（Domain）與外部資源（資料庫、UI、第三方服務）透過介面（Ports）與轉接器（Adapters）隔離WikipediaMedium。
優點： 清晰分層、易於測試與替換外部元件；強調核心領域模型純粹性。
缺點： 初期設計較為繁複；過度抽象可能導致開發效率下降。
適用場景： 大型複雜系統、需長期演進且高測試覆蓋。
2.7 微核心（Microkernel）架構
定義： 核心功能簡潔，額外功能透過外掛模組（Plug-ins）延伸Crowdbotics。
優點： 易於擴展與定制；核心穩定且輕量。
缺點： 外掛管理與相依處理複雜；適用範圍有限。
適用場景： IDE、插件驅動平台。
2.8 管線與過濾器（Pipes and Filters）架構
定義： 資料經過一連串過濾器（Filters）處理，管線（Pipes）負責傳輸，適合資料轉換與串流處理Wikipedia。
優點： 高度模組化、易於並行化。
缺點： 需處理中間資料格式；不適合互動式應用。
適用場景： ETL流程、大資料管道。
2.9 服務導向（SOA／Service-Oriented）架構
定義： 類似微服務，但服務粒度較大，多依賴ESB（Enterprise Service Bus）進行協調Wikipedia。
優點： 適用企業級系統整合；強調重用。
缺點： ESB成為單點瓶頸；治理成本高。
2.10 空間式（Space-Based）架構
定義： 透過分散式快取與資料格（Tuple Space）消除單一資料庫瓶頸，支援高併發需求Crowdbotics。
優點： 高可用與可擴展；避免資料庫成為瓶頸。
缺點： 複雜性高；需解決資料一致性與分片問題。
2.11 CQRS（Command Query Responsibility Segregation）與事件溯源（Event Sourcing）
定義： 讀寫分離，命令操作與查詢操作使用不同模型，搭配事件溯源可完整追蹤系統狀態變更Rajeev Singh | Coder, Blogger, YouTuber。
優點： 高度性能優化；自然支援審計與回溯。
缺點： 設計複雜，需同步維護多份模型。
