之前寫的感覺有點亂，把架構的設計圖先放上來吧，對照着說。
CAMCOCO架構能夠支持的模型：
1、B/S程序，比如CRM什么的，和訪問普通網站沒什么區別，都是從WEB服務器上進行操作；
2、APP的服務器端程序。APP可以是原生的，也可以是HTML5的。APP都通過WEB服務器獲取REST數據進行訪問，保護SOA的安全性；
3、WINFORM程序的服務器端；
從設計圖上可以看出，老胡把客戶端（使用場景）分為了三類：
1、不可信遠程客戶端：意思是可以被任何用戶使用的，我們無法確保用戶不會通過URL欺騙、COOKIE欺騙等等非法訪問的情況，SOA服務的訪問需要一個secrtKey，這個秘鑰是不能被客戶端掌握的，這種情況下，這類不可信客戶端只能通過WEB服務來作為跳板訪問SOA，而SOA的秘鑰則保持在WEB服務里，不直接交給客戶端。
2、可信任的遠程客戶端：在局部范圍內使用的一些場景，用戶身份和安全性是可以得到保證的，他們不會進行各種欺騙或嘗試破解獲得SOA秘鑰。那么他們可以直接訪問SOA服務進行操作。
3、可信任的本地客戶端：有一些本地化的服務，比如我們引入了消息中間件后，需要做一些消息隊列處理的服務時，就可以跨過SOA直接訪問業務層了。
WEB服務和SOA服務的集群化
集群化是一個比較高大上的名詞，其實老胡就是把各種服務給分解開來，從功能模塊級就開始進行解耦。
例如一個CRM里，老胡將功能系統進行拆分：
WEB集群
1、框架WEB： framework.camcoco.com
2、身份驗證WEB服務：passport.camcoco.com
3、組織架構管理WEB服務：org.camcoco.com
4、客戶管理WEB服務：customer.camcoco.com
5、訂單管理WEB服務：order.camcoco.com
6、....
SOA集群
1、身份驗證SOA服務：soa_passport.camcoco.com
2、組織架構管理SOA服務：soa_org.camcoco.com
3、客戶管理SOA服務：soa_customer.camcoco.com
4、訂單管理SOA服務：soa_order.camcoco.com
5、...
框架WEB負責加載一個CAMCOCO的Client Framework，里面包含了一堆老胡寫的JS，比如AJAX調用、場景保持及還原、數據提交驗證、CSS樣式等等。
其他的WEB服務都是一些輕量級的服務了，比如客戶管理里面，就只做和客戶相關的功能，比如客戶列表、查詢、新增、維護等等。
每個WEB服務后面是一個對應的SOA服務，WEB服務負責接收客戶端數據然后轉交給SOA進行處理。
這樣拆分之后，今后老胡要做一個新項目，里面也用到組織架構、身份驗證、客戶管理、生產管理，那我們直接就把之前的服務調用過來，然后新做一個生產管理就行了。（當然這是理想情況，客戶管理模塊多半還是要修改的）
如果賣出一套程序給某家用戶后，用戶說客戶這里我需要進行一些修改，那我們能很方便地定位到客戶這個模塊中，無論是從業務層開始修改還是只修改界面層，都是很方便的。同時在更新的時候，不會影響到其他功能模塊的正常使用。
至於業務層，老胡設計的實體中不包含操作方法，所有的操作都是放在聚合中進行，實體只負責數據合法性驗證。SO，老胡認為實體是可以交給之上任意層使用的，這樣在各層間傳遞參數時就可以直接傳遞實體對象，而不需要設計復雜的接口函數將實體的各個屬性分別傳遞下去了。
業務層里針對不同的服務包含了N多的業務單元，如上面的例子，那么里面就至少會包含CAMCOCO.Business.Customer和CAMCOCO.Business.Order，至於每個業務單元如何去設計，就根據需要了，比如你要用到消息中間件減輕壓力，比如要用到IOC實現業務靈活轉換。
總之，CAMCOCO設計的初衷就是：
1、每個業務都是可拆分可組合的，不同的系統可以共用盡量多的業務模塊；
2、在框架允許范圍內，盡量少的編寫代碼，且代碼是盡量規范的；
3、單獨業務（核心業務除外）不會影響全局系統的運行，不同業務可以交由不同人員完成，每個業務的不同層級也可以交由不同人員完成。
GO ON...