前言
從最開始的小公司做小網站，到現在進入現在的公司做專案，發現小公司里很多很多作業都是重復的勞動（增刪改查），不過想想也是，業務軟體最基礎的東西不就是增刪改查嗎，
但是很多時候，這種業務邏輯其實沒有必要挨個重寫，總不能說你的增刪改查比我的高級很多，很大程度上，復雜的問題只是資料太多了怎么優化，
簡介
在真的開始做之前，先來簡單介紹幾個概念，簡單介紹一下PaaS是什么，大概意思就是已經做好了一個大的平臺，你可以在上邊快速的配置、擴展你的服務，
詳細的介紹推薦看一下阮一峰老師的博客 http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html
概念上
我想從零開始搭建一個能夠配置定義業務，通過代碼擴展業務的平臺，在這個平臺上，簡單的需求，不寫代碼，復雜需求，只寫與標準不同的代碼，
有啥好處
提高生產力
其實，做軟體的大部分時候，都是在寫增刪改查，實在是太簡單了，搬磚誰不會對吧，要想搬得快，不需要你有多么好的腳力，更多的時候，你可能需要一個塔吊，
穩定的高負載
PaaS的設計之初，就是為了比較大的資料量來考慮的，專案小的時候，怎么著都行，但是，資料量一旦上來之后，小的專案可能根本沒法用，如果是PaaS平臺的話，你可能只需要多幾臺機器就完了，還是基礎組搞的事情，
分工明確
提到了高負載，其實很大程度上都是底層的事情，普通的開發，更多的好處只是性能的提升，那么就需要兩撥能力不同的人來共同完成這件事情，搞底層的更專注性能、擴展，搞業務的就更關注自己的核心業務就完了，
更少的服務代價
這個指的是客戶花銷，也是PaaS對于傳統軟體的優勢，PaaS平臺一旦做完，他肯定已經有平臺了，如果要開發新的功能，可能并不需要占用更多的資源，只是在原有的資源上增加點業務而已，況且PaaS服務商與客戶更多的是提供服務的續租模式，多一個客戶少一個客戶，其實對于服務器來說并沒有啥壓力，同一個團隊能夠服務與更多的人，
開發更快
就算是往小里做，如果你有這么一個PaaS的框架，你想要在上邊直接搞一個業務的話，其實也就是搞點配置，然后作為一個單機軟體部署，純定制開發也會變得更快，
具體點 我們要做什么
假設我們現在要做一個人員管理系統，我們一般需要以下內容，
- 增加資料
可以配置一個或者多個新增資料的頁面，點擊保存就保存了資料
- 洗掉資料
可以配置個按鈕，點擊一下就把相關資料洗掉掉
- 修改資料
可以配置個按鈕，點擊一下出現一個編輯頁面，里邊會出現對應的資料，你可以修改，然后點擊一下更新，資料就更新了
- 查
-- 串列頁面
你可以在串列頁面，配置幾個篩選項，然后你修改完資料之后，點擊搜索，就會根據你的資料來改變串列內容資料
-- 詳情頁面
你可以在串列頁面點擊名稱（點擊哪個可以配置）然后，就會自動跳轉到詳情頁面
詳情頁面要展示哪些內容也可以通過配置來進行修改
NoCode能力
這個是整個業務的核心，也是PaaS之所以可以將幾個月的作業量濃縮為數周的原因所在，
其實就是一個簡單想法的轉變，原本我們要實作我上邊畫的幾張圖，都是考改變代碼來實作，比如說串列頁面應該是戰士什么Title、串列要不要出現選擇框、串列究竟展示那幾列、右上角究竟有什么按鈕等等，
現在將這些原本需要寫到代碼里邊的邏輯整理到配置里邊，然后通過解釋這些配置，渲染出頁面，渲染出邏輯，
LowCode能力
當然了，上述的情況太過于簡單了，基本上就是一個資料庫的內容簡單展示而已，如果我們需要更復雜一點的內容呢？
比如說我們需要輸出這個人的年齡分層（幼兒、少年、青年、中年、老年），我們要怎么做呢？
很顯然這個狀態不應該被存放在資料庫中的，因為這個實際上是通過年齡動態計算出來的，過一年之后這個展示狀態可能就會過期了，這個時候我們就需要能夠動態插入邏輯根據年齡計算這幾個值，然后輸出結果，
當然這并不是全部了，其他還有很多需要解決的事情，比如
- 使用配置來實作渲染，配置資料，讀取起來是不是要比寫代碼慢很多？
- 搜索條件可能有很多，怎么實作這些條件可用呢？
- 如果默認的頁面滿足不了我的需求怎么辦？
- 業務權限要怎么處理？總不能進入系統的人都有權限吧？
- 開發完了這個玩意怎么發布到線上去？
- ... ...
這個玩意有點龐大，一口氣說不完，這次內容就這么多，我也只能一邊整理一邊寫博客，這可能會是一個很長，也可能是做不下去很短的系列，
寫的不好，能力有限多多見諒
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/3090.html
標籤：架構設計
上一篇：微服務的版本選擇思考與總結