前言
在對待項目上，有一種極端是認為每個項目都是特殊的，不可能和其他項目有共同之處；這算是一種經驗主義吧。 甚至有些程式設計師唯大項目不做，認為只有大項目才能鍛鍊自己，做過大項目的認才是牛人。
這些誤區都是因為我們軟體基礎知識的缺失，沒有人告訴我們，大小不同項目是否有共同點？ 我們現在做的項目需求是處於所有項目需求領域中何種位置？為滿足這個業務需求我高質量高效率完成了這個軟體系統，那么在這個軟體系統中體現的解決方案是否適合其他項目中其他類似的需求呢？
以前，通過設計模式我們已經完成了設計上重用，再通過重用框架，可以更高效粒度高大地更高質量地實現大部分系統， 但是，看上去同一個業務需求，在不同的項目，每次還是需要我們對這些框架進行重新組織設計，哪怕它們有些相同之處， 例如： 在電子購物系統中有商品和用戶兩種重要元素，商品本身是一個物，而且可能有層次類別區分；商品和用戶必然發生關係；在論壇系統中也存在帖子和用戶兩個元素，帖子是一個物，本身也有 類別區分，每個帖子必然和一個用戶發生聯繫。這兩個系統使用J2EE實現，當我們進行建模分析時，發現彼此之間隱約有一些共同之處。具體架構時又會涉及到表現層、業務層和持久層設計，兩者幾乎都可以使用相同的架構如（Struts+Jdon+Hibernate） 等等。
那么，能不能省卻我們在每個項目上都會這些類似相同的需求重新再做一次設計架構呢？如果設計模式重用是針對一個具體設計場景而實現的重用，現在我們幾乎不再滿足這種細粒度的低效重用效率，如果我們能抓助軟體源頭：業務需求，總結出某一類問題的共同之處，那么與之相聯繫的整個解決方案 也許就能夠得到重用，這種重用粒度更大，從而更高帶來開發效率。
但是，有一個問題：不同項目的業務需求之間到底是否有共同之處？大項目和小項目的業務需求是否有共同之處？ 我們每做一個項目，是否可以達到一葉知秋的效果呢？
業務需求在我們軟體系統一般用Model來統指，筆者曾經提出：域建模、模式和框架是Java軟體的三個大方面， 其中域建模起著關鍵龍頭作用，如何分析業務需求，如何實現正確的類圖（建模）表達，是決定整個系統成敗所在。更有這樣的觀點：No model,no patterns ,then no framework Model代表業務場景，沒有業務需求，就沒有設計模式，也沒有框架。
幾年前誕生的MDA是在這個方向進行了探索，很多先驅大師更在這方面進行了理論探索，如果說OO是對現實世界的一種抽象，那么MDA是比OO更加抽象的一種技術或方法論。“我們在一個軟體革命的開始，它象90年代我們看到的面向對象編程從傳統過程語言中抽象出來一樣。”
原型ARCHETYPEs
原型一詞來自於希臘語archetypo (arcetupo), 意味著 "original pattern." （原始模式）
比如英雄這個原型在美國或在中國看上去可能不一樣，但是英雄就是英雄，我們還是能夠很快地總結出英雄的一些特點。 因為原型是人類組織、總結和概括客觀世界的基本概念，我們完全有理由在軟體開發領域套用這些概念。
業務原型business archetypes
OO軟體系統是對業務領域（business domain）的思考抽象並進行管理操作，注意業務領域這個概念，我們相信應該能在業務領域中發現原型，或者在軟體系統；或者這些系統模型中。我們稱這種原型類型為業務原型（business archetype）
一個業務原型應該是一個在業務領域或商業軟體系統持續發生並且普遍存在的最初級的事物。
Party是一個業務原型例子，一個Party代表可標識的、可定位的單元或單位，這些單位有正常的 狀態。 通常一個Party用來表示某個人或某個組織。所有商業系統都或多或少有Party概念。
原型之間是相互互動的，Party, Product, 和 Order是每個虛擬商業系統的基本概念，在這個商業系統中，你可以賣產品或服務。我們將這些原型之間的協作看成是業務原型模式(business archetype patterns).
業務原型模式business archetype pattern定義：它是在業務領域或商業軟體系統持續發生並且普遍存在業務原型之間的協作。
原型（Archetypes）和分析類（analysis classes）區別
分析類（analysis class）是代表問題域中一種即時抽象，它對應真實世界的業務概念。
設計類（Design class）是一種達到可以實現程度的類。分析類是用於理解業務；而設計類用於理解技術解決方案，例如設計模式。分析類是從問題域（業務需求）中提取的，並沒有具體實現特點； 而設計類包含來自問題域（業務需求）和解決域（e.g., J2EE, .NET, or Web services）的特性， 從設計模式的使用特點可以了解這些，有人曾經單純拿出一段if else語句，而不考慮問題域； 就試圖使用某個模式替代這段if else，這就是因為他沒有認識道設計類的這個特點。
原型總是比正常的分析類更加抽象，屬於位於目前抽象層次的更高端，因此，通常原型模式可以生成一個或多個分析類。
原型模式和分析模式的關係怎樣，原型模式是分析模式嗎？不是，從定義範圍上看，原型模式有很多特性看上去要比分析模式多。分析模式是首先由Matin Fowler提出並定義如下："分析模式是一組概念，這些概念代表業務建模中一個普遍的構建，它也許和一個域相關；或跨越多個域。 其中並沒有任何原型的概念。
原型模式比分析模式要更加豐富，體現以下幾點：
原型模式可以使用UML來表達（Together中可以實現）； 原型模式可以作為一種平台獨立Model（PIM）適合MDA開發流程； 而這些分析模式則都不可以。
四色原型是誕生於90年代，現在被廣泛使用的一種系統分析方法，如Borland的Together架構師版，準確地說，是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然後由David North拓展[Coad95-97]
moment-interval role catalog-entry-like description party, place or thing前面已經說過，域建模是整個軟體系統的龍頭，在現代Java技術如JiveJdon3.0開始之前，我們都是需要領域建模，也就是在UML中畫出類圖，然後標記上類圖四種關係（關聯、依賴、繼承和實現），但是這些只是UML圖的表面，只是一種畫圖技巧，就象CAD畫圖一樣，你可能沒有被告知：這個類圖是怎么出來的？為什麼選用關聯而不是依賴，這些實際都屬於分析領域的知識，而四色圖可以說為我們這種分析提煉提供了一種模板或分析框架，這樣我們可以按圖索驥去分析每個陌生的系統，我們擁有強大的分析方法工具。
moment-interval archetype
這是一個很重要的原型，重要在於時間概念上：某個時刻(moment)或一段很短時間(interval)內. 意味在某個時刻發生的事情因為業務要求或合法性原因需要跟蹤；或者過一段時間以後，應該是很短的時間，可以幫助我們尋找到它。
賣東西是在某個時刻發生的，它有發生日期和時間。租賃行為是在一段時間內發生，從開始出租和歸還所租物品；預定也是持續一段時間，什麼時候預定；什麼時候過期等。
這些我們都使用moment-interval原型來表達，UML圖如下：
四色原型Moment-intervals是和組件模型捆綁在一起，代表了組件模組關注的核心和靈魂，在一個Model中，Moment-intervals經常封裝的是最關鍵的方法，為讓其顯目，moment-interval的UML圖我們使用粉紅顏色表示。在代碼上用@標識符標識：
/** @archetype moment-interval*/
public class Sale {
public BigDecimal calcTotal(){
}
private int number;
private Date date;
}
在任何領域中，我們都能尋找moment-intervals原型並且開始建模，在原材料資源管理系統中，我們可以這樣對待從報價單（RFQ）到購買訂單（PO）直至發票，在一個製造管理系統中，我們也就可以將一個計畫的過程和步驟分析到實際過程和詳細步驟。
原型在幫助指導建模方面一個有效方式是：它能標識那些被包含在Model模型中的類（Classes）以便於區分，原型不只是簡化了類的區別；原型還可以區分類的行為職責（responsibilities），例如類的屬性，方法等。
role archetype
角色原型比較容易理解，任何一個系統都需要人或某個組織介入運行，例如論壇系統需要註冊者角色發言；銷售訂單需要業務員角色制定，等等。
這裡有一個Party原型定義：它表示一個可標識、可定位的單元，這個單元有自己正常的狀態並且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等註冊性標誌等都可以作為Party。
注意，並不是說Party或人或組織就是Role原型，必須Party或人或組織參與一種活動後才為角色，就象張三在電影中表演皇帝，他只有參與電影表演才是皇帝角色；李四在XX公司的角色才是經理，他只有參與這家公司運作才是角色經理；否則他們只是一個Party原型。
所以，Role角色是Party扮演的（a role that a Party plays），Party是角色Role的扮演者（role-player）。
當我們在建模時，對於一個角色扮演者，可以有他自己的核心屬性如名稱、年齡（以人為例子），也可以有與業務相關的方法，比如一個小店，當店老闆去收錢時，他的角色就是收銀員（cashier），此時可以將與收銀員角色相關業務特點加於其上；當然，同時他也可以是老闆（Owner）角色。那么下圖中authorizedFor方法就是參與每個角色的行為，當他作為某個角色被授權登錄後，與此角色相關的業務特點就套用在他身上。
四色原型大家已經注意到了：角色原型在UML中是使用黃顏色標識的。角色模型是第二重要的原型，所以使用黃色。
我們已經知道，Party是一個又自主行為、能夠控制自己行為的表示，如人或組織，還有其他沒有自主行為的表示，也就是某個地方或位置或某個事情，我們一般稱( place, or thing)，不但Party可以成為角色，而且 place或thing也可以成為角色，比如，一個商品Product可能又兩種角色：在銷售過程中商品；正在使用的商品。
party, place, or thing archetype
上面我們說過，party place或thing都可以成為角色原型，注意到角色原型中的UML圖，party圖是以綠色表達。
Party表示有自己正常的狀態並且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等註冊性標誌等都可以作為Party。
Place or thing表示一樣不會說話沒有行為的東西，例如商品，當然這個商品可以扮演不同角色，既可以是零售的一個電源插座；也可以批發系統中的一個電源插座，它是被賣的，可能在不同業務系統被賣的方式不一樣。
description archetype
種類description原型其實是第三重要的原型，一般情況下，它類似目錄級別catalog-entry-like的種類，例如某個商品電源插座屬於家用電器這個種類，當然家用電器又屬於電器這個目錄，是一個樹形的目錄結構。例如論壇中帖子和回帖之間也是一種種類原型。
比如你的紅色福克斯是福特生產的一輛轎車，它有車牌號、購買日期、顏色和里程表等，這些代表Thing原型，那么作為轎車這個種類來說，它有一些種類屬性，例如：生產廠家、生產批號、適用顏色等，這些屬性是轎車這類所有車輛都共有的。
在設計模式這個實現級別，我們通常使用組合模式來實現種類原型。
四色原型Description原型在UML中使用藍色表達。
四色原型每個原型圖有屬性和連線（關聯 依賴等關係）兩個部分組成。
上一個章節我們談論了四色原型的基本定義，四色原型好像是這樣一個場景抽象：某人參與某活動對某事情操作，基本上我們人類的所有活動都可以用這段抽象來表達，這說明四色原型幫助我們更快地分析分辨事物。
下面我們以Java Modeling in Color with UML書中案例詳細說明一下四色圖深入意義，如下圖：
四色原型我們按照某人對某東西做某事的思路來理解上圖，不同的是，上圖中研究的不是某人(party)如何，而是研究Thing，如圖中綠色類圖中<<thing>>的標識。這樣，這張圖表達的是某個東西在一個活動或流程中發生的一些行為。
藍色的description種類原型負責尋找這類東西中一個實例（圖中findAvailable方法）並計算可用實例的數量，這兩種功能都需要和左邊綠色party對象互動。綠色的thing是判斷自己是否可用（圖中isAvailable方法），如果可以就返回一個最佳化的值；如果不是，向藍色的種類原型要求返回一個預設值；黃色角色是判斷這個東西是否適合它的角色，這幾種方式都是和粉紅的moment-intervals發生互動的。粉紅的moment-intervals原型可以創建這樣一個東西實例（圖中makeMomentInterval方法，支持業務過程來創建）；增加細節（圖中addDetail方法）或組成部分；並且計算總和(calcTotal)；它也接受外界訊息查詢當前活動是否完成或者取消了（圖中Complete和Cancel方法）等等。
用途之一：有助於正確的域建模
當我們接到一個軟體項目時，首先是了解業務需求，這個過程是一個互動逐步深入的過程，了解業務需求有多種方式，如國外普遍推崇的Use Case，畫出用例圖和客戶反覆確認；或者在中國，由於客戶層次限制，我們可能使用界面驅動方式，美工製作員首先製作出界面流程，供客戶直觀確認，反正方式多種多樣，這不在本文討論範圍之內。
本文關心的是，當你採集到正確的業務需求後，你是使用什麼方式把它傳導到軟體系統中，或者說：如何保證軟體系統解決的正是你的業務需求？如何保證這兩者之間對接完全正確，因為對接傳導不正確導致軟體系統失敗的案例太多了，最後表現為軟體人員和客戶互相推委，損失的是雙方時間和精力，這是誰也不想看到的，可是難道沒有可依賴的科學方法嗎？
這正是域建模所要解決的，每個業務需求總是有一定的解決問題，一個業務需求不可能解決世界上所有問題，所以業務需求提出的是一定範圍內的問題，是一種域問題，而隨之解決方案軟體系統也是一種域解決方案，所以，在這個域中正確將業務需求傳導到軟體系統很正確，這就取決於我們的域建模。
談到域建模，有人會問：在域建模概念出現之前，我們也做軟體系統，那時是用什麼分析方法？很顯然，我們是使用資料庫建模（使用powerDesign這樣傳統工具），依靠分析人員對這個行業過去的經驗和走過的路，設計出數據表結構，然後交給程式設計師寫SQL等數據CRUD增刪改查方法，這是一種完全依賴資料庫的分析設計方法，筆者已經在“資料庫時代終結”一文中指出過，這種方式已經過時，資料庫建模不能完全反應系統的全部特性和需求，使用同樣一套資料庫，完全由兩套優差不同的設計方案和代碼，從JiveJdon3.0和JiveJdon2.5兩個版本完全可以明白： http://cosoft.org.cn/project/showfiles.php?group_id=5298，這兩個版本都是使用同一個資料庫結構，但是卻是完全截然不同的設計和代碼，軟體的維護型和可擴展性就完全不同。
資料庫驅動分析不僅帶來業務需求和軟體系統對接不正確，導致軟體系統失敗，而且，這種分析方法過於依賴系統分析人員的經驗背景，導致系統分析員都是業務人員，而非專門的建模專家，不懂設計的業務人員還是無法做到軟體系統和業務需求的正確對接，還是范域範圍不對的老問題。
還有一種觀點認為，域建模不過就是使用UML畫出類圖，他以前設計過這個領域的數據表，換成類圖就可以了，類圖和資料庫建模圖似乎表面一樣，好像都是靜態關係表達，其實不然，類圖其實是動態的，是一種隱形動態，使用四色圖表達的類圖則是一種包含順序圖的完全動態圖，可以說類圖是立體多維的，而資料庫模型圖則是完全靜態的。
那么當我們進行系統分析設計時，如果有一個類，到底應該給它標記什麼顏色呢？也就是說將其歸類為哪個原型呢？通過這種歸類上顏色可以確證我們這個類提取的是否正確？或者可以說，我們可以按照四色原型從業務需求中提取抽象類，從而畫出類圖。我們可以按照下面考慮順序：
第一：它是不是依賴時間上瞬間或一段短時間存在的，是不是業務需求需要跟蹤記錄的對象？如果是，它就是momentinterval原型（簡稱MI）。
第二：然後，它是不是角色呢？如果是，就屬於黃色Role原型。
第三：然後，它是不是屬於一種目錄式的種類性質對象，或者代表一組呢可以反覆使用的概念，如果是，它就是藍色description原型。
第四：最後，它是某人或組織？或者是某個地方或者某個東西？那它就是綠色的party, place, or thing （簡稱PPT）。
可以將一個複雜的系統劃分成一塊一塊，從而有助於設計實現，當我們一個系統有好幾百個類圖時，如果不採取四色原型進行歸類，那么無疑很混亂，甚至類圖提取不正確，概念重複，甚至只有在系統代碼實現時才會發現如此嚴重問題，這對於分析設計來說無疑時重大打擊。
Domain-Neutral Component(DNC)
一個業務系統是由多個四色圖反覆拼裝而成，我們稱為這種現象是Domain-Neutral Component模式，如下圖（圖片來自Step10）所示：
四色原型這樣，我們可以將一個複雜可能是成千上萬個類的類圖劃分成一個個小碎塊，達到清晰分類的目的。你可以使用這種基於語義的類圖模板進行任何系統的域建模，DNC最好的優點是異常的簡單好用，你不必將你的模型Model填入DNC，而是DNC指導幫助更加完整地建模。
很多人認為類圖是靜態的；而順序圖是動態的，其實類圖是隱形的動態；而順序圖只是顯式的動態，順序圖是將動態執行過程完全表現出來，而我們從類圖上好像看不到這點，其實你可以在四色類圖中發現更多順序圖的影子，四色圖中幾乎無需另外使用順序圖來補充表達，而整個DNC內部的所有互動都是這樣的，這無疑是令人激動的，也就是說，使用包含四色圖的DNC已經可以完全表達一個系統了。
我們先看看類圖中是如何虛擬表達業務三維系統中的聯合association：
四色原型如圖中上半部分，左邊和右邊兩個類的關係association是用0..*表達，這說明是一個一對多關係，實際意思是圖中下半部分，一個左邊對應右邊多個，所以，我們要從圖中表達看到更加深遠的意思，上半部分比下半部分表示更加節省空間，也只是空間上簡化。
那么，如果左邊的對象向右邊的對象傳送訊息，形成互動動作了，是不是一定要使用方法method和順序圖來表示，為什麼我們不能象上面空間簡化一樣進行動態簡化，如下圖：
四色原型我們可以在類圖中表達順序互動動作，這就是DNC作出的一個貢獻。所以從一張DNC圖的關係中，我們可以清楚的表達前後發生的循序調用。比如上面DNC圖中一旦一個PartyRole訪問Momentinterval，將首先訪問PriorMI，還有MomentintervalDetails（當然，該圖中沒有列出方法，所以具體確切走向無法得知）。
十二種複合組件(Compound Components)
這12種複合組件是所有企業業務系統的抽象，說白一點，所有企業系統業務需求分析到最後，基本上都可以用這12種複合組件代表，換句話說：搞懂這12個組件模型，你就基本能迅速分析弄懂幾乎的企業系統，從而進行快速的設計編碼，這12種組件可以說是業務需求的復用，從而能使我們站在前人的基礎上更快更準進入企業軟體系統的分析和設計開發。
這12種複合組件是：
| Make a Buy Sell Relate Coordinate and Support MaterialResourceMgmt ProductSaleMgmt HumanResourceMgmt ProjectActivityMgmt FaclilityMgmt CashSakeMgmt RelationshipMgmt AccountingMgmt ManufacturingMgmt CustomerAccountMgmt DocumentMgmt InventoryMgmt |
需要詳細了解這些原型組件可參考Java Modeling in Color with UML一書。
Jdon框架套用
Jdon Framework作為一個新興的開源框架，可能有很多人對其是否能夠承受複雜套用表示懷疑，其實這些我們都是可以從四色圖理論上進行論壇證。
以Jdon框架套用JiveJdon3.0為例，該系統使用Jdon框架其實已經完成了四色圖需求，如下圖
四色原型這已經說明使用Jdon框架可以完成一個四色圖需求實現，而根據DNC理論，複雜的系統基本是由多個四色圖重複組成，因此，我們完全可以反覆使用Jdon框架，通過完成一個個四色圖這樣的基本單元，從而以組件拼裝方式完成一個較為複雜的套用系統。
四色圖和DNC理論實際上是我們面對大型紛繁複雜需求時的一個定心丸，同時也是檢驗一些新興理論開放框架的一個基礎平台。從此我們可以輕鬆地使用四色圖分解出項目需求，從而確保項目系統實現完全符合原始需求，跨越項目需求和項目實現不對接這個鴻溝，也許以後我們不再會發生下面的情況：當我們辛辛苦苦用最新絢麗的技術完成軟體系統後，興致勃勃介紹給用戶時，用戶卻說：這不是我想要的東西。
