|
數(shù)據(jù)可配置化、界面可配置化、功能可配置化、流程可配置化 SaaS可配置化：數(shù)據(jù)可配置化針對(duì)SaaS多租戶模型，本文分析了如何實(shí)現(xiàn)拓展數(shù)據(jù)的可配置。 針對(duì)SaaS多租戶模型，在實(shí)際運(yùn)行過程中會(huì)發(fā)現(xiàn)不同的租戶需要保存不同的特殊字段，例如，就拿CRM系統(tǒng)而言，A租戶希望能保存客戶紀(jì)念日，來源等，而這些數(shù)據(jù)對(duì)應(yīng)B租戶而言并不需要。這種系統(tǒng)實(shí)現(xiàn)過濾中并不存在，而用戶又需要被保存的數(shù)據(jù)，稱為拓展數(shù)據(jù)。顯然，不同的客戶需要保存的拓展數(shù)據(jù)可能是完全不同的。 對(duì)拓展數(shù)據(jù)的處理，在傳統(tǒng)模式中是完全不存在問題的，因?yàn)閭鹘y(tǒng)軟件模式一個(gè)客戶對(duì)應(yīng)一套軟件及數(shù)據(jù)庫實(shí)例，系統(tǒng)可是實(shí)現(xiàn)根據(jù)客戶的要求定制化數(shù)據(jù)庫實(shí)例。但在SaaS模式，多個(gè)客戶對(duì)應(yīng)同一套實(shí)例，如依舊采用傳統(tǒng)定制化模式，數(shù)據(jù)庫必將產(chǎn)生大量多余的字段，進(jìn)而影響數(shù)據(jù)的性能。 針對(duì)SaaS多租戶模型，對(duì)于拓展數(shù)據(jù)，最常見的解決方案就是實(shí)現(xiàn)拓展數(shù)據(jù)的可配置，包含如下三種主流的解決方案。 1：定制字段該解決方案更多還是在傳統(tǒng)軟件中被采用，根據(jù)用戶的實(shí)際需求，在數(shù)據(jù)表中增加相應(yīng)的字段。 如系統(tǒng)只有一個(gè)用戶，那么定制字段可以完美的滿足用戶及技術(shù)需要。 但針對(duì)SaaS對(duì)租戶模型，如還為每一個(gè)客戶都添加字段，那么勢(shì)必會(huì)使表中字段多如牛毛，而且隨著定制字段的增多，將產(chǎn)生大量無意義字段，嚴(yán)重影響數(shù)據(jù)庫性能。 2：預(yù)分配字段預(yù)分配的實(shí)現(xiàn)邏輯就是在設(shè)計(jì)數(shù)據(jù)表結(jié)構(gòu)時(shí)，預(yù)留設(shè)計(jì)多幾個(gè)無意義的字段，根據(jù)實(shí)際運(yùn)行過程所需的業(yè)務(wù)要求，為對(duì)應(yīng)的字段賦予實(shí)際的業(yè)務(wù)意義。 例如A客戶需要額外留存訂單號(hào)，那么預(yù)分配A字段的對(duì)于A客戶而言保存的就是訂單號(hào)，B客戶需要額外需要座機(jī)號(hào)，那么預(yù)分配A字段對(duì)應(yīng)B客戶而言就是座機(jī)號(hào)。 預(yù)分配字段在一定程度滿足租戶對(duì)于拓展數(shù)據(jù)的需求，但并不是完美的解決方案，依舊存在如下不足點(diǎn)：
3：名稱值對(duì)引入配置元數(shù)據(jù)表的概率，數(shù)據(jù)庫表分為拓展數(shù)據(jù)表、業(yè)務(wù)數(shù)據(jù)表、配置元數(shù)據(jù)表。 業(yè)務(wù)數(shù)據(jù)表負(fù)責(zé)存儲(chǔ)統(tǒng)一 的業(yè)務(wù)邏輯數(shù)據(jù)，拓展數(shù)據(jù)表存儲(chǔ)根據(jù)租戶需求而新增的拓展數(shù)據(jù)，而拓展數(shù)據(jù)表與業(yè)務(wù)數(shù)據(jù)表通過元數(shù)據(jù)配置表關(guān)聯(lián)。引入元數(shù)據(jù)噢誒子表，實(shí)現(xiàn)拓展數(shù)據(jù)的橫向拓展，而且完全由租戶業(yè)務(wù)驅(qū)動(dòng)，不造成數(shù)據(jù)的浪費(fèi)及混亂。 誠然，不管是定制字段，預(yù)分配字段還是名稱值對(duì)，所針對(duì)的都是數(shù)據(jù)庫的設(shè)計(jì)，本文主要還是介紹產(chǎn)品人員怎樣構(gòu)建SaaS應(yīng)用，對(duì)于涉及偏向技術(shù)性的問題，這里只大致介紹一下，有興趣的小伙伴可以自行查找相關(guān)資料就行了解。 SaaS租戶來源于各行各業(yè)，為適應(yīng)本行業(yè)的特點(diǎn)，租戶必然會(huì)提出定制界面的要求，而SaaS應(yīng)用不可能像傳統(tǒng)軟件一樣，部署時(shí)為特定的用戶定制化開發(fā)符合要求的界面。因而實(shí)現(xiàn)界面的可配置化成為SaaS模式的必要要求。 ｜SaaS可配置化：界面可配置化SaaS應(yīng)用不可能像傳統(tǒng)軟件一樣，部署時(shí)為特定的用戶定制化開發(fā)符合要求的界面，因而實(shí)現(xiàn)界面的可配置化成為SaaS模式的必要要求。要想實(shí)現(xiàn)SaaS界面的可配置化分別關(guān)注如下三個(gè)可配置點(diǎn)。 一、菜單名字可配置化不同行業(yè)有不同行業(yè)的專用術(shù)語，例如：CRM系統(tǒng)中的客戶管理，在汽車金融公司就需要改為SP管理，客戶資料管理就應(yīng)該改為進(jìn)件管理。這些菜單名稱的配置及動(dòng)態(tài)展示，是SaaS系統(tǒng)實(shí)現(xiàn)跨行業(yè)使用所必備的基本要求。 二、菜單層次結(jié)構(gòu)及分布的可配置化為了更符合用戶的使用習(xí)慣，菜單的層次結(jié)構(gòu)及分布也需要進(jìn)行可配置化，筆者在做庫存監(jiān)管項(xiàng)目時(shí)就有遇到過，有的客戶需要把入庫審核、出庫審核、挪庫審核、臨時(shí)出庫審核按照嚴(yán)格的順序排列，而有的客戶需要把各類審核統(tǒng)一歸納到審核管理母菜單中。 所有作為SaaS系統(tǒng)十分有必要實(shí)現(xiàn)菜單層次結(jié)構(gòu)及分布的可配置，在實(shí)際操作過程中需要注意如下幾個(gè)問題： 一個(gè)租戶一套菜單； 一個(gè)菜單可以關(guān)聯(lián)一個(gè)原子功能； 組織成樹狀結(jié)構(gòu)，構(gòu)成上下級(jí)菜單結(jié)構(gòu)； 同級(jí)菜單間存在顯示順序的問題。 三、頁面元素可配置 與功能菜單類似，各功能頁面上的內(nèi)容也是供用戶與系統(tǒng)交互的界面元素。不同的租戶可能也會(huì)有不同的定制化需求，無論是對(duì)頁面元素的位置、個(gè)數(shù)、順序，還是元素的含義，個(gè)租戶都會(huì)有一定定制化需求。 前面在《SaaS可配置化：數(shù)據(jù)可配置化》中有提到，租戶可根據(jù)自己的實(shí)際業(yè)務(wù)需求定制化拓展數(shù)據(jù)，這些定制化的拓展數(shù)據(jù)就會(huì)涉及到在頁面展示的問題，不同的租戶，頁面元素個(gè)數(shù)可能完全不一樣。 同時(shí)，在系統(tǒng)設(shè)置時(shí)，雖然一般情況下是不允許用戶刪除這些界面元素，但有時(shí)還是需要給予用戶權(quán)限，讓用戶對(duì)一些無關(guān)緊要的元素進(jìn)行隱藏。 同時(shí)針對(duì)同一個(gè)頁面元素，不同的租戶可能可能需要定義成不同含義，例如：在新建客戶時(shí)，針對(duì)“客戶姓名”這個(gè)標(biāo)簽，有的租戶可能會(huì)定義成“顧客姓名”，“有的租戶會(huì)定義成”代理商姓名“。另外對(duì)于元素的排序，位置不同的租戶也會(huì)有不同的定制化需求。 幸好，現(xiàn)在網(wǎng)上已有大量的前端框架可實(shí)現(xiàn)上述的定制化要求，有興趣的小伙伴可以自行查找 所以，對(duì)于SaaS產(chǎn)品實(shí)現(xiàn)界面可定制化，需要注意實(shí)現(xiàn)菜單名字，菜單層次結(jié)構(gòu)及分布，頁面元素的可配置。
一、劃分原子功能 所謂的原子功能也就是系統(tǒng)最小的組成單位，原子功能與原子功能間相互獨(dú)立，互不重疊，所有的原子功能具有如下原則：
劃分原子功能的最基本原則就是“每個(gè)功能都具有價(jià)值“，而且這種價(jià)值是相對(duì)用戶而言的。只有對(duì)用戶具有價(jià)值的功能才會(huì)被用戶購買。 例如新建賬號(hào)時(shí)，系統(tǒng)會(huì)對(duì)管理員輸入的手機(jī)號(hào)及信息進(jìn)行驗(yàn)證，但這種驗(yàn)證只是新建賬號(hào)的一個(gè)步驟，并不能為用戶帶來任何價(jià)值，也就不能劃分成單獨(dú)的一個(gè)原子功能。 除關(guān)注功能所具有的價(jià)值外，劃分原子功能時(shí)，需基于既定功能架構(gòu)盡量細(xì)化，做到每個(gè)劃分的原子功能都是不可細(xì)分的。例如針對(duì)表單的錄入，用戶在創(chuàng)建時(shí)往往會(huì)區(qū)分新建表單和提交表單，這兩個(gè)操作對(duì)用戶而言都是具有意義的，所以劃分原子功能時(shí)，拆分新建表單和提交表單兩個(gè)原子功能，會(huì)更清晰，更靈活。 在進(jìn)行分解時(shí)，還需要關(guān)注原子功能之間的關(guān)聯(lián)關(guān)系，做到不可細(xì)分，互不重疊。 注意，功能的分解需要保持系統(tǒng)的完整性，也就是說，劃分出來的所有原子功能，要覆蓋整個(gè)系統(tǒng)的功能，而不存在沒有被劃分的系統(tǒng)功能，確保系統(tǒng)功能的完整性 二、功能定義及依賴 在實(shí)際操作過程中，作為產(chǎn)品人員，還需要對(duì)劃分的原子功能進(jìn)行定義和建立原子功能間的依賴關(guān)系。 所謂功能定義其實(shí)就是對(duì)原子功能進(jìn)行描述，定義它的名稱，關(guān)鍵字，內(nèi)容等相關(guān)信息。其中名稱和內(nèi)容便于對(duì)原子功能進(jìn)行詳細(xì)的描述，而關(guān)鍵字，重在對(duì)該原子功能進(jìn)行唯一標(biāo)識(shí)，在系統(tǒng)上需要時(shí)刻確保改該標(biāo)識(shí)的唯一性。 除對(duì)原子功能進(jìn)行描述，在劃分過程中我們會(huì)發(fā)現(xiàn)，并不是所有的原子功能都可單獨(dú)使用，有些功能需要依賴其他功能才能使用，功能與功能間存在一定的依賴關(guān)系。 例如，很多B端管理系統(tǒng)都具有“查看操作日志”這種功能，但“查看操作日志”往往依賴于“查看數(shù)據(jù)列表”，如果租戶沒有購買“查看數(shù)據(jù)列表”這個(gè)功能，那“查看操作日志”也是不能使用的。 所謂的功能依賴，就是指一個(gè)功能在沒有另外某些功能的情況下是不能使用的 。 三、功能包設(shè)計(jì) 通過劃分原子，對(duì)原子功能進(jìn)行定義，及設(shè)計(jì)原子功能的依賴關(guān)系。我們基本實(shí)現(xiàn)了對(duì)系統(tǒng)功能的梳理，回到我們的出發(fā)點(diǎn)：為應(yīng)對(duì)客戶的“按需購買”而實(shí)現(xiàn)功能的可配置。 但其實(shí)，光具有原子功能，并不能高效的實(shí)現(xiàn)功能的可配置。 通過逐步細(xì)化及劃分，系統(tǒng)原子功能數(shù)量急劇增加，可達(dá)到幾十個(gè)，甚至可達(dá)到上百個(gè)。直接對(duì)這些原子功能進(jìn)行管理是超級(jí)復(fù)雜的事情。而且這些原子功能之間的使用并不是完全獨(dú)立，很多功能操作是相關(guān)。 例如客戶的新建，查看，編輯，刪除這些功能都是一起使用，往往不存在單獨(dú)使用的情況。并且在前一步中我們也了解到，劃分的原子功能之間是存在依賴關(guān)系的，而這些具有依賴關(guān)系的原子功能總是綁定起來一起使用，從使用場景也可以看出，具有相同使用場景的原子功能不是具有操作關(guān)聯(lián)性就是具有依賴性。 所以在原子功能的基礎(chǔ)上，整合具有操作關(guān)聯(lián)性及依賴性的原子功能，以功能包的形式統(tǒng)一管理是十分有必要的。 所謂的功能包就是一組具有關(guān)聯(lián)性，依賴性的原子功能的集合體，功能包的設(shè)計(jì)遵循高內(nèi)聚，低耦合的原則，具有關(guān)聯(lián)性的原子功能聚合在一起，而功能包與功能包盡量減少依賴關(guān)系，進(jìn)而保證每個(gè)功能包都盡可能單獨(dú)的進(jìn)行操作使用。 四、定義銷售包 功能包已經(jīng)將具有關(guān)聯(lián)性的原子功能集合在一起了，但對(duì)于客戶而言，定義好的功能包仍不能單獨(dú)使用。所以為了讓客戶購買后能夠充分使用系統(tǒng)，還需要按不同的商業(yè)意圖構(gòu)建適合用戶使用銷售包。 銷售包只是一種以向用戶銷售而定義功能包。例如但凡成型的SaaS應(yīng)用都會(huì)有最小版，標(biāo)準(zhǔn)版，完整版?；虼嬖诎纯蛻羲鶎傩袠I(yè)而定義的服務(wù)行業(yè)版，制造行業(yè)版等。這些都可以稱之為銷售包。 五、功能使用校驗(yàn) 在前面已經(jīng)定義了原子功能，功能包，銷售包。在實(shí)際使用過程中，對(duì)用戶操作權(quán)限的校驗(yàn)還是基于原子功能的，通過驗(yàn)證改用戶是否具有改原子功能的操作權(quán)限，進(jìn)而實(shí)現(xiàn)系統(tǒng)功能權(quán)限的控制。
|
|
|
