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