OO的"沉重"，architecture design(架構設計)

初步建立
從需求捕捉=>分析=>設計=>code，由OOAD到OOP是一件不簡單的工作，從UP來說，可能的流程是這樣的

Use cases=>analysis model=>design model=>code

如果簡單的說，就是找出需求，分析的時候分離出名詞跟動詞，將其組合成物件，跟著抽象化倒出analysis model，借用design pattern設計出模型，最後寫出程式碼

中間過程

似乎很簡單，但是中間很多空隙(gap)需要填充，比方說UP推崇architecture centric的思維，那麼如何找出architecture?這是一個很困難的工作

為了設計architecture，UP擴展了許多東西，首先他們在use cases內部添加了一些constraints，表達non-functional features，比方fault tolerance、performance ...，這些非功能性的限制，跟著引入了controller、boundary object以及entity組成的collaboration diagram

利用sub system interface做切割，填補design以及requirement之間的縫隙，並且完成其中的對應(tractability在CMMI很重要!)

建構架構

UP中architecture centric的設計方式有賴經驗，而且要take care的重點很多，很難一概而論，同時要考慮user centric、functional features跟non-functional features，導致作法多樣，同時為了抽象表示的不足，在UP才引入collaboration diagram

在設計architecture的時候可以考慮Matrin Folwer的建議，使用domain model，可以使用DDD (domain driven design)模式，DDD一口氣跳過分析方式，直接由需求到設計，而DDD面臨的兩個議題是，模型的描述語言以及分析的方式

在DDD的部分，使用domain model是很好的選擇，跟UP的collaboration diagram很像，然則也不是那麼容易。主要一個議題是，如何符合iterative建構?如果要辨識出所有的需求再來考慮architecture，整體就變得類似waterfall的設計方式

模型的描述語言DDD使用類似class diagram的模型，並且加上類似use case的補充來描述，客戶專家以及程式設計師，必須懂得同樣的terms，DDD模型大多時候不考慮operations，連attributes也很少紀錄，畢竟是一種抽象思考。

另外一個議題是分析的方式，DDD利用design pattern填補分析方式的不足，DDD相信大家都可經由消化知識，抽象畫原本的議題，進而達成共識(領域專家未必能接受這種語言)，其次這裡的design pattern也與GoF不大一樣，主要注重抽象的層級

另外一種architecture的設計方式類似DDD，首先確立業務目標(白雲，參考writin effective use case 一書)，接著確立範圍以及特色(風箏跟海平面)，同時利用類似use case的上下文(context)來分割出architecture的輪廓，本質上跟DDD很類似，但是只是比較方法論去形塑domain model

不管DDD或者是使用UP的cooperation diagram，重點必須找出重要的(考慮各種non-functional feature)、主要的(risk)、使用者最關心的(user centric)，來做為architecture model，如果單純依照UP提示的，找出涵蓋整個系統，一寸深的architecture，我想只有非常資深的設計師才能做到，且有太多不必要的考量因素

還缺了甚麼?
architecture相當程度是為了演繹一些系統重要的部分，形成重要的骨幹，然則與DDD/Domain model有點不大一致，Domain model主要是要表達整體的概念，而DDD則是以Domain model為依歸衍生設計
可以說architecture是Domain model的主要部分，用以檢驗是否滿足各種需求(functional and non-functional)