在企業系統開發中，API 架構扮演關鍵角色。它不僅是前後端溝通的橋樑，更是跨模組、跨服務協作的核心。相較於 REST 著重資源導向、gRPC 聚焦高效能與嚴格協定，JSON-RPC 則提供一種更靈活且結構化的方案：以方法為核心設計，格式輕量、請求與 JSON 高度相容，極適合需要明確業務流程邏輯的應用系統。 除了架構彈性，JSON-RPC 更具備資料編碼上的延展性。在 Bee.NET 的設計中，JSON-RPC 的資料傳輸流程可支援 MessagePack 序列化、壓縮與加密，確保資料在內部系統或跨網路傳輸時兼顧「效能」、「安全」與「易於維護」。相較於 protobuf，MessagePack 在動態物件結構與 .NET 環境中更具開發友善性，且不需維護 .proto 檔案，開發流程更簡潔。 Bee.NET 架構同時支援「近端除錯」與「遠端部署」兩種呼叫模式，能大幅提升開發效率並降低部署成本。本文將以 jsonrpc-sample 專案為例，展示如何構建一套模組化、可維護、具備資料編碼與雙模式呼叫能力的 JSON‑RPC 架構。 📦 專案來源：jsonrpc-sample on GitHub 🧱 為何選擇 N‑Tier 架構與近／遠端雙模式？ 在企業級系統（如 ERP/HRM）中，常見的 N‑Tier 架構會將應用程式邏輯分層：

📌 前言 在開發 ERP 系統時，選擇介面形式（Windows、Web、Mobile App）並不是單純的技術選擇，而應從實際使用情境與企業流程的複雜度出發，做出最適合的判斷。 對中小企業來說，由於流程簡單、人數不多，全面 Web 化通常可以達到集中部署與維護的目標；但對於流程繁複的大型組織而言，若統一採用 Web UI，可能會在操作效率與使用體驗上打折扣。因此，應根據不同角色的使用情境，靈活選擇合適的前端介面，才能兼顧效率與彈性。 本文將從使用者角色的角度出發，提供 ERP 系統介面規劃建議，協助企業打造符合實務需求的多端架構。 🎯 規劃目標 以「人」為核心，根據使用者的角色、操作情境與使用頻率，分配最適合的介面型態（Windows、Web、App），提升整體效率與滿意度，同時兼顧系統彈性與可維護性。

在多人協作的 Git 專案中，如何設計清晰的分支管理流程，往往直接影響到開發效率與產品穩定性。這篇文章分享我們公司在實務上採用的「四分支策略」，搭配出貨與雲端部署的實際情境，供大家參考。 🎯 我們的四大分支角色 分支名稱 用途 對象 備註 dev 日常開發

本文探討 SaaS 系統在架構設計與部署過程中，如何兼顧 擴展彈性 與 成本控制，並提供在 Azure 雲端平台的實務觀察與建議。內容涵蓋應用與資料層分工、部署彈性設計、快取與資料庫分區策略、以及多雲部署可行性，適合系統架構師、雲端工程師、DevOps 與技術主管參考。 一、設計原則建議 ✅ 推薦做法 業務邏輯應集中於應用層，而非資料庫更利於維護、版本控管、自動部署與測試。 應用層可橫向擴展，提升彈性與可用性。 資料庫聚焦於資料儲存與查詢 避免過度依賴 Stored Procedures、Triggers 等邏輯。

延續上一篇 企業系統的 N-Tier 架構設計，本篇介紹如何依此理念，嘗試使用 AI Coding（GitHub Copilot）實作一套模組化的 .NET 開發框架 —— Bee.NET Framework。 ✨ 為什麼叫做 Bee.NET？ Bee.NET 命名靈感來自「蜜蜂的分工協作」與「蜂巢的穩定結構」： 蜜蜂透過分工協作，共同建構六角形蜂巢，每個蜂巢格既獨立又彼此連結，形成最穩固的結構。 Bee.NET 中的每個元件就像蜂巢格，依責任模組化構建，組合成穩健且可擴充的系統架構。 🌟 Bee.NET 不只是技術名稱，更是一種架構哲學 ——「如蜜蜂般專注協作，打造模組化、可維護的企業應用系統。」

比較三種常見的 API 通訊技術：JSON-RPC、gRPC、REST，涵蓋傳輸格式、效能、擴充性、適用場景等面向。 📊 技術特性比較 特性 / 技術 JSON-RPC gRPC REST 🔧 傳輸協定 通常使用 HTTP/HTTPS（POST）

For internal enterprise systems such as ERP, CRM, or HRM platforms, adopting an N-Tier architecture is a common and effective practice. It enables clear separation of concerns, modular design, and strong scalability. This article outlines a five-layer N-Tier architecture tailored for enterprise systems, explaining the responsibilities and characteristics of each tier. Overview of the Five-Tier Architecture Layer Name Description Presentation Layer Provides the user interface (UI), such as WinForm, Web UI, or mobile app UI. API Connector Layer

在企業內部使用的 ERP/CRM/HRM 系統開發中，採用 N-Tier 多層式架構 是常見且有效的方法，可達到清楚的職責分離、良好的模組化與系統延展性。本文介紹一套適用於這類型系統的五層式架構，並說明各層的角色與特色。 N-Tier 架構五大分層 分層名稱 英文名稱 說明 表現層 Presentation Layer 提供使用者介面（UI），如 WinForm、Web UI、APP UI。

嗨，我是一個寫 ERP 系統架構寫了超過 20 年的軟體架構師。 這個部落格，我打算用來記錄一些實務開發上的心得、踩過的坑、解過的奇葩問題 ——也就是那些你在書上看不到、教學影片裡也沒人講的東西。 我的故事，從 2000 年開始說起… 大學讀機械設計，研究所跑去工工所主修 AI，2000 年畢業後靠著國防役進了一家 ERP 套裝軟體公司。剛好公司那時要把老舊的 Client/Server 系統重新打造為支援 Windows 跟 Web 的三層式架構，也就這麼剛好，我被推去當了架構設計的第一線苦工。從此開啟我與「系統架構」之間的愛恨糾纏 —— 從此，一腳踏進這條不歸路。 而我拿到的第一個任務，就讓我至今印象深刻： 因為 Crystal Reports 授權太貴，主管問我能不能自己寫一套報表引擎，Windows 跟 Web 都能用的那種。

簡介 項目 Protobuf MessagePack 格式類型 二進位格式，需定義 Schema 二進位格式，類似 JSON 結構 設計目的

JSON-RPC 2.0 是一個輕量級的遠程程序呼叫 (RPC) 協議，使用 JSON 格式作為訊息交換格式。它支持單向呼叫、通知、批次請求及回應，並提供錯誤處理機制。JSON-RPC 2.0 並不限制實作細節，這讓它可以廣泛應用於不同的應用場景。 訊息結構 每個 JSON-RPC 訊息包含以下基本元素： 1. jsonrpc 類型: 字串 描述: 指定 JSON-RPC 的版本。對於所有 JSON-RPC 2.0 訊息，該字段應設為 "2.0"。 2. method

比較項目 .NET Standard 2.0 .NET Framework（例如 4.8） .NET（例如 .NET 8） 是否可執行 ❌ 不可（僅為共用庫標準） ✔️ 可執行 ✔️ 可執行

📌 1. GetAuthorizationUrl (授權網址產生) 參數名稱 是否標準 說明 client_id ✅ 是 OAuth2 用戶端應用的 ID。 redirect_uri

1. 概要 技術名稱 全名 用途說明 OAuth2 OAuth 2.0 Authorization Framework 授權框架，用於第三方應用存取資源，不處理身份驗證 OpenID Connect