兩階段開發的目標設定
重點說明
本案例的演練區分為兩個釋出 (release)階段。在現實的專案開發，每一個釋出版本都應該是可以滿足使用者的功能需求。兩個釋出版本的重心為：
第一個階段：快速實現功能需求，但保留了可以具延展性的 3-tier MVC框架。
第二個階段：找出穩定的共用元素，讓系統更有彈性。
第一個階段 (release #1)在內部的開發週期分為兩個循環 (iteration)。第一個循環 (iteration #1)快速實現幾個具代表性的使用案例，並打通技術關節。而相關於邏輯處理或欄位細節等，則留待第二個開發循環 ； 所以第二個開發循環 (iteration #2)著重在於對精細度的要求，包括欄位細節、企業規則的邏輯 (business rule logic)，以及對於例外事件的處理 (exception handling)。
第二個版本的釋出 (release #2)，則除了在於擴展系統功能外，還希望能就維護性、彈性度等議題來作調整。此階段重點在於對系統組成結構的重整 (物件與資料結構)，或亦可在程式碼上對其重構 (re-factoring)。結構重整或重構皆為共用性設計議題的整合考量，所耗費的開發成本往往比較高 (但也相對容易提升系統的價值)，且須具備相當基礎的軟體設計素養才有能力將軟體做軟 (keeping software soft)。
兩個不同階段時期的釋出版本要能順暢的橋接，至少要能有兩個必要的條件：
- 3-tier MVC (Model-View-Controller) 實體IT框架。
- 以使用案例為單位的功能性測試程式碼 (function test code)。
＊＊ 關於 Release 與 Iteration 的意義與差異，可參考：
http://www.kenming.idv.tw/soft_development_iteration_vs_release-2
Release #1 (包含 Iteration #1, #2 兩個開發循環)
目標：從使用案例 (功能需求)快速導出到程式碼實做。
簡述：以使用案例為單位，找出最具價值的使用案例，優先開發。
作法：
以服務為開發的導向，為每一個使用案例設計功能性的控制物件 (位於中間層)，並將實現該功能案例的邏輯 (Logic)落實於該物件內，實際連結資料庫來存取資料作運算；同時並撰寫功能測試程式碼，確保程式碼的正確性。再來則是透過 UI 表單的實作，來驗證功能。
效果：
本階段並不重視資料與企業邏輯的共用性，而是以個別的使用案例為開發單位，快速實做出可執行與可被測試的應用程式碼，滿足使用者對系統功能的要求。
但系統內部則保留可以延展的框架，確實將企業邏輯 (business logic)集中於中間層 (middleware)來，隔離 UI 層與資料庫的緊密耦合 (tight-coupling)，實現 MVC (Model-View-Controller)架構。
資料與企業邏輯功用性的考量，非影響系統的功能，而是與系統的彈性度有關，這是當專案具有再利用性價值，或是產品需要高度客製化的考量時，再施以第二個階段的系統結構重整。
Release #2 (包含結構重整階段)
目標：萃取出穩定的結構共用元素 (企業物件，business object)，讓系統更有彈性。
簡述：從多個使用案例中，找出共用的企業邏輯，施以結構的重整。(重構，Refactoring)
作法：
- 觀察多個使用案例，是否有具共用性的邏輯。 例如 「Place a Order」, 「Track Order Info」這兩個使用案例，可能均有「計算訂購總額()」的企業邏輯 (business logic)。
原來在第一個開發階段沒有考量共用設計的情況下，是可能個別被實現在各自的使用案例控制物件 (control object)內。在結構萃取的整合階段，則會發掘出共用的部分，並分派該計算邏輯至合適的企業物件內，如「計算訂購總額」可能會被分派至「Order」的企業物件內，成為該物件的操作 (operation)。
- 觀察是否有「有點像又不太像」的企業規則(business rule)。 例如 「保險」的「計算保費()」 操作，會因為有各種的保險類別，如 「意外險」、 「壽險」、 「產險」 …等，而有不同的計算邏輯，但都仍會有「計算保費」的計算邏輯，只是各自的演算邏輯不同。
這類「有點像又不太像」的功能，開發人員經常是以 switch, if then…else 這類的條件判斷來實做，但不容易應付需求變動且難以維護。此時則可以施以「多型 (polymorphism)」的設計觀念，將不同種類卻又共用相同操作名稱的計算邏輯，確實分派至各種不同的特殊化類別內 (意外險、壽險、產險…)，卻又能讓外界以「一視同仁」的角度 (只有看到「保險」的一般化類別)，來操作存取使用，卻又不需要直接與各類的特殊化類別直接耦合，而不致於被這些特殊化類別的變動所影響。
效果：
從控制物件「萃取(Extract)」共用性邏輯至其它如企業物件上。此一過程為物件導向中最常使用的技巧，稱為「委派(delegation)」，作用在於讓物件的責任分派 (responsibility)更明確，可以更確實的將變動侷限在可控制的範圍內，讓系統更能應付變動，更具彈性度。