盡量少的前言
雖然寫了N年代碼了，但總覺得什么東西都是囫圇吞棗，無法盡得其精髓。最近整理了一套心目中的架構，如有錯誤之處，煩勞不吝指正，老胡在此不勝感激！！
第一篇 我心目中的架構
做了無數個系統，寫了無數個項目，有幾個問題始終困擾着我。
總是重復做着同樣的功能，比如組織架構，比如權限模型；
代碼質量總是無法得到根本性的保障；
大量的功能性代碼重復，沒有被很好地抽象出來（其實就是設計模式沒有被很好地利用起來）；
過一段時間后修改代碼很困難，因為代碼風格總是隨着時間在不斷變化，並且大部分時候代碼都是來自好幾個人的。
我想有一個架構，它可以有以下一些特性：
1、利用EntityFramework實現ORM特性，在設計及編寫項目時，思路能最大程度地保持在業務本身，而不用跳出到數據庫設計上去；
2、借鑒DDD的設計思想，將業務邏輯封裝到聚合里（實際上我是很想完全采用DDD的，但是啃了半天書，因為沒有實際項目的實踐，在領域事件上仍覺得很模糊，並且對於聚合的實際應用方式也不是很清晰）；
3、將通用性的一些操作，比如增刪改查，抽象出來，放到業務邏輯的核心層去實現，每個業務邏輯不用再自己實現。這樣上層重復代碼量將會少很多；
4、規范一些基本操作的代碼寫法，在最大程度上確保上層代碼質量的可控性；
5、通過SOA模式，實現包括一站式登陸、權限判斷、通用（常用）模塊的獨立運行；
6、業務邏輯層不局限於對某一特定模式的UI層的支持，它應該能夠廣泛地支持WEB、MVC WEB、WINFORM、MOBILE（ios or android）端的調用；
總之，通過這個架構，我想能夠在編寫具體業務功能的時候使用盡量少、盡量標准的代碼來實現。
基於此，我對整個架構進行了如下一個層次划分：
01 UI 層代碼：這里是各種客戶端的代碼，我在其下做了個01.01 MVC WEB Application的目錄，如果有其他的客戶端，可以在這下面實現，比如增加一個 01.02 WIN FORM Application。
02 SOA：為界面層提供數據的服務層，這一層實際上是一個數據中轉層。我將業務邏輯中的各個聚合都通過SOA暴露給客戶端，那么不同的客戶端都可以通過統一的方式來對系統進行訪問了，實際上這一層也起到了一個防腐層的作用。當然，如果是本機運行的WIN FORM模式，或者不希望采用SOA模式，也可以在UI層直接調用業務邏輯層。
03 Business Logic：業務邏輯層，在這里面對不同的業務邏輯按照DDD的設計思想，設計為不同的聚合（Aggregate），這一層也是需要我們自己編寫的。SOA層與這一層進行通訊。
04 Model Logic：模型層，也就是實體層。我將業務中的實體對象單獨拆分出來，沒有和業務層放到一起，因為在UI層里都會用到各個實體的定義，而業務邏輯層我並不想直接交給UI層去使用。UI只需要知道自己當前使用的實體有哪些屬性可以使用就好。實體我采用的是充血模型，包括自我驗證等特性，這個會在后面說到。
05 Business Core：業務邏輯核心包（代碼），嚴格說來，帶Core名字后綴的都不是單獨的一層，只是一個基類。業務邏輯層的代碼都是從這個東西派生出來的，這里面包含了一些基本的、通用性的業務操作。
06 Model Core：實體層核心包，同上，我在這里給定義了集中標准的實體模型基類，所有實體都需要從這些標准基類中派生出來。同時在這里實現了一些實體的克隆、驗證等通用方法。
07 DATA：數據持久層。一直很糾結這里究竟要怎么做，尤其是對不同數據庫的支持上，最后因為自己一直使用SQLSERVER，所以這里直接就通過EntityFramework來實現了，EF本身就支持很多種數據庫，但沒測試過，至少在我的需求內，SQLSERVER是完全沒問題的。
08 General：通用描述定義，這里不能稱為一層了，我把一些常用的數據類型進行了標准化，實體類在使用這類屬性的時候直接從通用描述定義里取得就行，這樣利於實現數據格式的標准化，比如實現了數據鎖定狀態描述信息、數據過期狀態描述信息等。
09 Common：工具類，就是各種Helper，這里的工具可以根據需要隨時增加。
10 Reference Lib：引用的第三方類庫統一放到這個目錄下，方便查找。
11 Solution Documents：項目文檔什么的，都放這里就好。
12 Test Projects：單元測試代碼
13 Publish：項目發布目錄
額，下一篇從最底層寫起...