【文章內(nèi)容簡介】 。 該角色的工作，在運(yùn)營中一般由“實(shí)施工程師”來完成。 “ 租戶第一人 ”： 由租戶自己使用。這個(gè)“ 租戶第一人 ”是由“租戶管理員”分配的，租戶可以使用這個(gè)“ 租戶第一人 ”給自己的系統(tǒng)添加用戶。 “用戶”和“賬戶”在本文的描述中都是只用戶用來登陸系統(tǒng)的用戶名。 3 參考資料 《 SaaS 模式系統(tǒng)參考架構(gòu)設(shè)計(jì) .doc》 作者：陳操 《 MSYQL 數(shù)據(jù)庫備份與恢復(fù)及 SaaS 下的備份策略 .doc》作者：莫榮廣 4 系統(tǒng)功能分析 SaaS 模式下功能分析 從系統(tǒng)使用者的角度，整個(gè)系統(tǒng)的功能模塊劃分如下： S A A S 房 地 產(chǎn) 營 銷 管 理 系 統(tǒng) 1 . 0客 戶 管 理客 戶 跟 進(jìn) 管 理客 戶 信 息 管 理產(chǎn) 品 管 理開 發(fā) 商 及 項(xiàng) 目 資 料 管 理普 通 房 源 管 理服 務(wù) 管 理售 后 服 務(wù) 管 理系 統(tǒng) 設(shè) 置 管 理用 戶 管 理（ 組 織 架 構(gòu) 、 員 工 、 用 戶管 理 ）日 志 管 理權(quán) 限 管 理系 統(tǒng) 參 數(shù) 管 理報(bào) 表 管 理房 源 統(tǒng) 計(jì) 報(bào) 表 客 戶 統(tǒng) 計(jì) 報(bào) 表銷 售 統(tǒng) 計(jì) 報(bào) 表 ? ?系 統(tǒng) 交 互 接 口B O S S 系 統(tǒng) 交 互 接 口短 信 接 口郵 件 接 口 ? ?財(cái) 務(wù) 管 理誠 意 金 管 理 訂 單 款 項(xiàng) 管 理收 據(jù) 管 理 欠 款 管 理財(cái) 務(wù) 對 帳 銀 行 帳 號 管 理銷 售 管 理優(yōu) 惠 管 理 定 價(jià) 管 理銷 控 管 理 訂 單 管 理活 動(dòng) 管 理( 認(rèn) 籌 活 動(dòng) 、 開 盤 活 動(dòng) ）銷 售 工 具產(chǎn) 品 基 礎(chǔ) 資 料 管 理租 戶 信 息 管 理圖表 SaaS RES 功能模塊劃分圖 ? 系統(tǒng) 版本的產(chǎn)品只有普通房源，還不包括車位、花園、學(xué)籍等房地產(chǎn)附帶產(chǎn)品的管理 ? 銷售管理模塊和財(cái)務(wù)管理模塊是系統(tǒng)的核心業(yè)務(wù)模塊 ? 系統(tǒng)支持多租戶共同使用，但租戶的管理、租期管理等不屬于本系統(tǒng)的職責(zé)，由 BOSS 系統(tǒng)負(fù)責(zé)，系統(tǒng)與 BOSS 系統(tǒng)進(jìn)行交互，獲取 BOSS 系統(tǒng)提供的租戶相關(guān)信息和租戶啟用、 停用通知等信息 業(yè)務(wù) 功能劃分 子系統(tǒng)劃分 下面站在系統(tǒng)構(gòu)建者的角度出發(fā)，按業(yè)務(wù)處理、報(bào)表統(tǒng)計(jì)和基礎(chǔ)支持三個(gè)類別把系統(tǒng)進(jìn)行子系統(tǒng)劃分： S A A S 房 地 產(chǎn) 營 銷 管 理 系 統(tǒng) 1 . 0產(chǎn)品管理子系統(tǒng)前 臺(tái) 業(yè) 務(wù) 系 統(tǒng)后 臺(tái) 支 撐 系 統(tǒng)客戶管理子系統(tǒng)銷售管理子系統(tǒng)服務(wù)管理子系統(tǒng)財(cái)務(wù)管理子系統(tǒng)報(bào)表管理子系統(tǒng)參數(shù)設(shè)置子系統(tǒng)用戶管理子系統(tǒng)權(quán)限管理子系統(tǒng)日志管理子系統(tǒng)租戶信息管理子系統(tǒng)圖表 SaaS RES 子系統(tǒng)劃分圖 ? 租戶信息管理子系統(tǒng)主要包括 BOSS 系統(tǒng)發(fā)送過來的租戶相關(guān)信息，如租期到期提醒信息，租戶通知信息的管理 ? 用戶管理子系統(tǒng)包括了用戶的身份認(rèn)證，用戶管理和員工、組織架構(gòu)的管理 。 5 架構(gòu)設(shè)計(jì) SaaS 模式的架構(gòu)設(shè)計(jì)和普通系統(tǒng)的架構(gòu)設(shè)計(jì)有所不同， SaaS 除了要滿足用戶各種個(gè)性化要求以外，應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器要滿足成千上萬的請求，因此，對系統(tǒng)可用性、伸縮性、擴(kuò)展性以及性能提出了更高的要求。 本次參考架構(gòu)設(shè)計(jì)的總體原則就是：分割和緩存 。 架構(gòu)分析 下面主要綜合之前的功能性和非功能性的要求，來對系統(tǒng)的整個(gè)架構(gòu)進(jìn)行分析。 業(yè)務(wù)實(shí)體的增、刪、改及一些復(fù)雜的業(yè)務(wù)處理功能 分析： 對于 SaaS 房地產(chǎn)營銷管理系統(tǒng) （后面統(tǒng)一簡稱為 SaaS RES ）來說，對業(yè)務(wù)實(shí)體 的增、刪、改、操作是最常見的基礎(chǔ)功能，這些操作 都有一個(gè)共同的特征 —— 改變系統(tǒng)中的業(yè)務(wù)實(shí)體的狀態(tài)（或數(shù)據(jù)），因此，這里選擇基礎(chǔ)房間的增、刪、改這一典型的功能需求進(jìn)行分析，以闡述對于這類對業(yè)務(wù)實(shí)體狀態(tài)產(chǎn)生改變的操作的設(shè)計(jì)決策。 決策： 系統(tǒng)使用最常見的層式架構(gòu)進(jìn)行設(shè)計(jì)，按邏輯被劃分為：展示層、應(yīng)用服務(wù)層、領(lǐng)域?qū)雍蛿?shù)據(jù)訪問層，下圖展示了系統(tǒng)各邏輯層之間的關(guān)系： 展 示 層 （ W e b 層 ） 應(yīng) 用 服 務(wù) 層 領(lǐng) 域 層數(shù) 據(jù) 訪 問 層（ O R M ）D O R e p o s i t o r yD OD OD OD OD OD OS e r v i c eS e r v i c eS e r v i c eA c t i o nA c t i o nA c t i o nD O R p s t I m p lD O R p s t I m p lD O R p s t I m p l圖表 增、刪、改操作設(shè)計(jì)決策圖（充血模型） ? 展示層：負(fù)責(zé)為用戶提供用戶界面，接收用戶的輸入?yún)?shù)，提交給應(yīng)用服務(wù)層執(zhí)行相應(yīng)業(yè)務(wù)操作，并接收應(yīng)用服務(wù)層的返回結(jié)果展示給用戶，其直接依賴于應(yīng)用服務(wù)層。 ? 應(yīng)用服務(wù)層：向外提供業(yè)務(wù)功能服務(wù)，它只負(fù)責(zé)系統(tǒng)應(yīng)用級別的邏輯如事務(wù)控制、權(quán)限控制、日志處理等，以及少量的跨領(lǐng)域?qū)ο蟮臉I(yè)務(wù)邏輯，它通過領(lǐng)域?qū)拥念I(lǐng)域?qū)ο髠}庫獲取相關(guān)的領(lǐng)域?qū)ο?，然后調(diào)用領(lǐng)域?qū)ο蟮姆椒ㄍ瓿上鄳?yīng)的業(yè)務(wù)，再把業(yè)務(wù)結(jié)果封裝到數(shù)據(jù)傳輸對象（ DTO）中返回給展示層，這里的 DTO 是作為展示層與應(yīng)用服務(wù)層的數(shù)據(jù)載體，它負(fù)有裝載請求數(shù)據(jù)和結(jié)果數(shù)據(jù)的職責(zé)。 ? 領(lǐng)域?qū)樱?包含業(yè)務(wù)領(lǐng)域內(nèi)的一系列相關(guān)領(lǐng)域?qū)ο蠹捌鋫}庫接口，領(lǐng)域?qū)ο蠓庋b其領(lǐng)域內(nèi)的業(yè)務(wù)邏輯，領(lǐng)域?qū)ο笸ㄟ^其倉庫獲取和持久化。 ? 數(shù)據(jù)訪問層（ ORM）：提供領(lǐng)域?qū)ο蟮某志没瘜?shí)現(xiàn)，它的作用是把領(lǐng)域?qū)ο蟮木唧w持久化實(shí)現(xiàn)細(xì)節(jié)封裝起來，并利用 ORM 工具把數(shù)據(jù)庫中的數(shù)據(jù)轉(zhuǎn)換為領(lǐng)域?qū)ο?。該層只提供持久化?shí)現(xiàn)，持久化操作的接口由領(lǐng)域?qū)佣x，因此，該層依賴于領(lǐng)域?qū)犹峁┫嚓P(guān)領(lǐng)域?qū)ο蟮臄?shù)據(jù)結(jié)構(gòu)和持久化操作接口。 下面分別以系統(tǒng)中四個(gè)典型的功能用例來分別對業(yè)務(wù)實(shí)體的增、刪、改以及涉及復(fù)雜業(yè)務(wù)規(guī)則的業(yè)務(wù)操作進(jìn)行詳細(xì)分析： 用例 1：創(chuàng)建個(gè)人客戶信息 —— 業(yè)務(wù)實(shí)體的創(chuàng)建操作 創(chuàng)建個(gè)人客戶信息有如下的業(yè)務(wù)約束： ? 客戶的姓名、性別、聯(lián)系電話、客戶類型、是否重點(diǎn)客戶的標(biāo)識(shí)這些屬性都不能為空； ? 客戶的姓名和聯(lián)系電話組成了客戶身份的唯一標(biāo)識(shí)。 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，或者說面向?qū)ο笤O(shè)計(jì)的最重要規(guī)則是：把不同的職責(zé)合理的劃分到不同的對象中，根據(jù)這一規(guī)則，我們對上述的業(yè)務(wù)約束進(jìn)行分析： 客戶屬性是否必填，屬于客戶實(shí)體自身的業(yè)務(wù)完整性約束，因此，這部分職責(zé)應(yīng)該交給客戶實(shí)體本身負(fù)責(zé)； 客戶的姓名和聯(lián)系電話是客戶身份的唯一標(biāo)識(shí)，這意味著系統(tǒng)不能存在兩個(gè)具有相同姓名和聯(lián)系電話的客戶，這 就需要在創(chuàng)建客戶的時(shí)候進(jìn)行檢查，而這部分工作，對于客戶實(shí)體來說，它并不了解其他客戶實(shí)體的信息，因此，應(yīng)該交由其上層，客戶管理應(yīng)用服務(wù)負(fù)責(zé)。 根據(jù)上面的分 析，我們已經(jīng)可以清晰的劃分職責(zé)，然后得出如下的創(chuàng)建個(gè)人客戶的時(shí)序 圖： 創(chuàng)建個(gè)人客戶信息時(shí)序圖 用例 2：修改個(gè)人客戶信息 —— 業(yè)務(wù)實(shí)體的修改操作 修改個(gè)人客戶信息有如下業(yè)務(wù)約束： ? 修改個(gè)人客戶信息用例包含了創(chuàng)建個(gè)人客戶信息的所有業(yè)務(wù)約束； ? 當(dāng)系統(tǒng)設(shè)置了需要 開啟客戶信息修改審核功能時(shí)，如果修改了個(gè)人客戶信息中的核心信息，并且修改個(gè)人客戶信息的系統(tǒng)用戶不具有審核功能權(quán)限，則修改后的個(gè)人客戶信息不能直接更新，而是要把修改信息提交審核，審核通過后，才能更新對應(yīng)的個(gè)人客戶信息。 根據(jù)上述的業(yè)務(wù)約束進(jìn)行分析，系統(tǒng)是否開啟客戶信息修改審核功能，很明顯不屬于個(gè)人客戶實(shí)體的職責(zé)，因此它應(yīng)該由應(yīng)用服務(wù)層負(fù)責(zé)，同時(shí)，由于客戶管理應(yīng)用服務(wù)的職責(zé)是對客戶信息進(jìn)行管理，而客戶信息修改審核功能的設(shè)置是由系統(tǒng)參數(shù)設(shè)置模塊負(fù)責(zé)，所以，這項(xiàng)職責(zé)應(yīng)該由系統(tǒng) 參數(shù)設(shè)置應(yīng)用服務(wù)提供，而判斷是否修改了客 戶核心信息，很明顯屬于個(gè)人客戶的職責(zé)。最后，根據(jù)當(dāng)前系統(tǒng)用戶是否具有審核功能權(quán)限，這部分職責(zé)應(yīng)該由客戶管理應(yīng)用服務(wù)負(fù)責(zé)，由于權(quán)限判斷是由通用權(quán)限組件提供的功能權(quán)限判斷器來提供，前者會(huì)把任務(wù)委托給后者。經(jīng)過上述分析，得出下述的時(shí)序圖： 修改領(lǐng)域?qū)ο髸r(shí)序圖 用例 3：把個(gè)人客戶信息放入回收站 —— 業(yè)務(wù)實(shí)體的刪除操作 把個(gè)人客戶信息放入回收站有如下的業(yè)務(wù)約束： ? 參加過認(rèn)籌登記的客戶不能放入回收站； ? 交過錢（存在 財(cái)務(wù)付款記錄）的客戶不能放入回收站； ? 下過訂單的客戶不能放入回收站 ? 正在提交審核（被修改或合并后未審核通過）的客戶不能放入回收站。 分析業(yè)務(wù)約束，認(rèn)籌登記、財(cái)務(wù)記錄、訂單都屬于客戶實(shí)體的從屬信息，即客戶實(shí)體與上述實(shí)體形成聚合關(guān)系，按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的理念，客戶實(shí)體是上述實(shí)體的聚合根，所以，判斷客戶是否有過認(rèn)籌登記、財(cái)務(wù)記錄和訂單都應(yīng)該是客戶實(shí)體的職責(zé)，然而我們再進(jìn)一步分析，實(shí)體的職責(zé)是相對的，在不同的業(yè)務(wù)上下文，業(yè)務(wù)實(shí)體所具有的業(yè)務(wù)職責(zé)是不同的，把個(gè)人客戶信息放入回收站這一個(gè)用例，其業(yè)務(wù)上下文局限于客戶管理， 因此，在這一范圍內(nèi)，客戶實(shí)體并沒有認(rèn)籌登記、財(cái)務(wù)記錄和訂單等概念，客戶實(shí)體是一個(gè)職責(zé)單一的實(shí)體，而上述概念分別來源于銷售管理服務(wù)（包括認(rèn)籌登記、訂單）和財(cái)務(wù)管理服務(wù)（財(cái)務(wù)記錄），對于客戶管理應(yīng)用服務(wù)來說，其業(yè)務(wù)上下文同樣與銷售管理服務(wù)、財(cái)務(wù)管理服務(wù)無關(guān)，所以，判斷客戶是否參加過認(rèn)籌登記，是否有財(cái)務(wù)記錄， 是否下過訂單的職責(zé)既不應(yīng)該由客戶實(shí)體負(fù)責(zé)，也不應(yīng)該由客戶管理應(yīng)用服務(wù)負(fù)責(zé)（由于銷售和財(cái)務(wù)是客戶的下游業(yè)務(wù) —— 銷售和財(cái)務(wù)都是基于客戶的，所以依賴關(guān)系是前兩者依賴于后者，如果由客戶管理應(yīng)用服務(wù)負(fù)責(zé)，則客戶管理應(yīng)用 服務(wù)必須委托銷售管理應(yīng)用服務(wù)和財(cái)務(wù)管理應(yīng)用服務(wù)提供判斷結(jié)果，這就形成客戶管理與銷售管理、財(cái)務(wù)管理形成循環(huán)依賴關(guān)系，這違背了模塊化設(shè)計(jì)原則）。進(jìn)一步分析，上述判斷邏輯都只是一種查詢服務(wù)，并不會(huì)對任何業(yè)務(wù)實(shí)體產(chǎn)生狀態(tài)影響，因此，可以通過在客戶領(lǐng)域?qū)ο髠}庫中提供一個(gè)特殊的查詢服務(wù)來獲取。我們再分析最后一個(gè)業(yè)務(wù)約束，由于客戶是否需要審核是由系統(tǒng)設(shè)置決定的，因此該判斷邏輯同樣不屬于客戶實(shí)體的職責(zé)范圍，應(yīng)該由客戶管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置服務(wù)完成，綜上所述，得出如下時(shí)序圖： 注：該用例表達(dá)的是邏輯刪除的場景，物理刪除的場景與此基本一致，唯一的不同是需要在業(yè)務(wù)處理的最后通過實(shí)體對應(yīng)的倉庫從持久層中把對象刪除。 用例 4：客戶下訂單（即創(chuàng)建訂單） —— 典型的復(fù)雜業(yè)務(wù)處理功能 客戶下訂單有如下的業(yè)務(wù)約束（注：由于該用例業(yè)務(wù)功能非常復(fù)雜，而且在結(jié)構(gòu)設(shè)計(jì)階段，銷售模塊的需求分析還沒完全完成，因此該用例的業(yè)務(wù)約束將忽略一些不是很重要的細(xì)節(jié)，該用例的最終模型和時(shí)序圖以銷售管理模塊的詳細(xì)設(shè)計(jì)為準(zhǔn)）： ? 下訂單 時(shí)可以根據(jù)系統(tǒng)參數(shù)的設(shè)置同時(shí)修改客戶信息； ? 只有狀態(tài)為“可售”的且有定價(jià)的房間可以進(jìn)行下訂單； ? 當(dāng)系統(tǒng)參數(shù)設(shè)置組合房間可以拆開銷售時(shí)，組合房間和基礎(chǔ)房間都可以下訂單，否則，被組合的基礎(chǔ)房間不可售； ? 根據(jù)系統(tǒng)參數(shù)設(shè)置判斷是否可以使用歷史價(jià)格； ? 如果有客戶有進(jìn)行認(rèn)籌登記，需要對認(rèn)籌登記進(jìn)行解籌，并把認(rèn)籌金額轉(zhuǎn)換為定金； ? 需要根據(jù)各種優(yōu)惠及款項(xiàng)信息計(jì)算訂單的總折扣率和折后總房價(jià)； 分析業(yè)務(wù)約束，第一個(gè)業(yè)務(wù)約束很明顯不屬于訂單實(shí)體及其他相關(guān)實(shí)體的職責(zé)，由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷，當(dāng)可對客戶信 息進(jìn)行修改時(shí)，還需要委托客戶管理應(yīng)用服務(wù)提供修改服務(wù)；房間是否可售需要根據(jù)房間狀態(tài)決定，這職責(zé)明顯是由房間實(shí)體負(fù)責(zé)；已組合的基礎(chǔ)房間是否可售，由系統(tǒng)參數(shù)設(shè)置決定，所以應(yīng)該由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷，至于房間是否已經(jīng)被組合，這是房間實(shí)體本身的職責(zé)；可否使用房間歷史價(jià)格，由銷售管理應(yīng)用服務(wù)委托系統(tǒng)參數(shù)設(shè)置應(yīng)用服務(wù)進(jìn)行判斷；對于解籌操作，訂單實(shí)體包含認(rèn)籌登記記錄，因此應(yīng)該由訂單負(fù)責(zé)；訂單的總折扣率和折后總房價(jià)是由訂單的各種優(yōu)惠及款項(xiàng)信息決定的，因此屬于訂單的職責(zé)，但進(jìn)一步分析，總折扣率和折 后總房價(jià)可能由不同的計(jì)算方式，因此，應(yīng)該設(shè)計(jì)一個(gè)訂單總折扣率和折后總房價(jià)計(jì)算器實(shí)體，并由訂單委托其進(jìn)行計(jì)算，綜上所述，得出如下時(shí)序圖： 客戶下訂單時(shí)序圖 這個(gè)時(shí)序圖的設(shè)計(jì)并不是最終的客戶下訂單用例的時(shí)序圖，它主要表達(dá)了一個(gè)復(fù)雜的業(yè)務(wù)，需要通過合理的抽象以及對業(yè)務(wù)變化的預(yù)見性，建立好合理的模型，并把職責(zé)合理的劃分到不同的服務(wù)或領(lǐng)域?qū)ο笾校瑥亩玫礁玫撵`活性或擴(kuò)展性，這也是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心思想。 對象 的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù) 分析： 對象的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù)同樣也是系統(tǒng)的典型操作，與對象的增、刪、改不同，對象的查詢業(yè)務(wù)、報(bào)表業(yè)務(wù)的共同特征是： 1）這些操作不會(huì)改變業(yè)務(wù)實(shí)體的狀態(tài)和數(shù)據(jù)； 2）這些操作返回的數(shù)據(jù)量可能比較大； 3）這些操作查詢的結(jié)果很多時(shí)候是跨領(lǐng)域?qū)ο蟮臄?shù)據(jù)視圖； 4）這些操作通常比較頻繁； 5）這些操作不需要調(diào)用領(lǐng)域?qū)ο蟮木哂袠I(yè)務(wù)意義的方法。 基于這些特征，如果使用“充血模型”設(shè)計(jì)方法，就會(huì)出現(xiàn)一系列問題