本集介紹

最近筆者剛好遇到一個開放性較大的系統案例，分享給大家思考看看你們會怎樣去做規劃。

先簡單說明一下技術背景，資訊商是有點歷史了，所以主要開發會以微軟服務和基本網站 CRUD
去做規畫；這次主要服務對象是傳統產業，傳統產業對於技術的需求基本上都不會太大，除非有明確的技術轉型，就算是技術轉型也很少養開發團隊，這就要看公司產業和目標了。幸運的是用戶正在規劃 SSO(Single Sign On) 所以本次接手的項目可以使用 API 服務，讓這個系統設計各家的多元。

現有系統有兩個站台服務說明如下：

權限後台(API 服務提供方)
使用對象：企業內部使用以資訊人員為重
系統功能：網站操作基本的新增、修改、刪除、更新，有提供傳統自訂義 API
系統服務：管理帳號權限，帳號會對應一個角色權限，如：帳號 角色 功能權限；可在角色 上掛載功能和設定傳入的參數。
背景資料：有固定排程執行Stored Procedure做資料處理Mapping

服務平台(需求方)
使用對象：企業內部使用和外部使用者
需求說明：服務平台須建立一支功能給資訊人員建立使用者帳號
技術方案：網路可請求權限後台、網站可與權限後台資料庫溝通，Stored Procedure Data Mapping
現有流程：使用者登入會請求權限後台 API，服務平台每支功能都需透過權限後台請求功能

我相信第一眼看過去一定會選擇使用 API 方式來完成該需求，但是事為什麼呢？這邊分享我的思路

Support this show: https://pay.firstory.me/user/cjkewxl4t1it00770icmlwsx5
Leave a comment and share your thoughts: https://open.firstory.me/user/cjkewxl4t1it00770icmlwsx5/comments
。資訊欄相關連結可至 Firstory 平台點擊；如果內容對你有幫助歡迎贊助 Donate。

Powered by Firstory Hosting