「Core J2EE Design Patterns 」一書，提出了許多實用的設計樣式(Patterns)，以應用在 J2EE(尤其以 EJB 為核心)平台環境下的最佳實務與設計策略。

整本書將所揭露的樣式整理分類為三個階層(tiers)：Presentation Tier、Business Tier、Integration Tier。

對應問題領域(Problem Domain)所建構的物件模型(Object Model)，在 UML 是以類別圖(Class Diagram)來實作的，是位於 Business Tier 所稱之的 Business Object。而類別圖亦即為整個軟體系統的核心結構。結構分析與設計的好壞差別，會明顯反應在系統的效能與需求的變動管理上。

尤以後者，最重要的設計考量：如何將變動侷限在一小塊範圍之內。
為了達成此一目的，「低耦合性(loose coupling)」與「高內聚力(high cohesion)」是在設計的階段中，時常所需要觀照與調和的。

位於 Business Tier 內 Session Facade、Application Service 兩個樣式的揭露，即在於期望能達成上述「低耦合性」與「高內聚力」的設計考量。

我看了許多篇國外的文章與討論，發現到許多 Developer 並不是很瞭解這兩個樣式的目的與應用。其實仔細去觀察思考，這兩個樣式均旨在 "保護企業物件(Business Object)"， 為了保護企業物件，所以需要能封裝(Encapsulate) 客戶(Client)端 直接對企業物件的存取。除了封裝的考量外，另外也需要有一個控制協調的角色，稱之為控制物件(Control Object)。來協調多個企業物件之間的互動合作。

所以，上述兩個樣式的設計應用，是誰負責封裝？、誰負責控制呢？
從該書的內容，許多讀者會以為 Session Facade 是負責封裝，Application Service 是負責控制協調。
其實，不然不然，兩者都可以是封裝的角色，也可以是控制者的角色。

而事實上，Session Facade、Application Service、Business Object 三者的關係是源自於 MVC (Model-View-Controller) 的設計模式。MVC 樣式的目的即在於解開不同類型物件(例如 UI 物件與企業物件)之間的糾結，增進系統的彈性與元件的再利用性。參考如下圖一。

圖一、MVC 設計模式的對應關係

若從另外一個角度來觀察時，Session Facade 是可以 "聚合(aggregiate)" 多個 Application Service，以組合併實現更為複雜的企業流程。此時，Session Facade 是擔任著主要控制協調者的角色，而 Applicatin Service，成為可以被 "共用(Share)" 的企業流程物件了。參考如下圖二。

圖二、SF、AS、BO 實作 Controller、CBPO、CBO 三個階層的關係

閱讀全文 »

什麼是系統內部的結構(Structure)？

• 系統內部(內涵)，由某些單元或元素所組合而成為一個整體(Whole)。
• 系統被視為一個整體時，即具備了系統功能(System Functions)，可以提供服務(Services)，以應付外部的需求。
• 系統作為一個整體時，其應付外部需求變動的彈性(Flexibility) 取決於內部的結構分析(Analysis)與設計(Design)程度。
• 莫僅從表面看事務，即便連藝術家如達文西，在描繪人像時，會去研究及實驗人體解剖，以觀察及瞭解人體結構的奧妙。

什麼是系統的結構分析與設計？

• 找出與描述系統組成結構的元素 – 分析(Analysis)；尋求一個解決方案(Solution)，利用結構內部的元素，動態組合以滿足外部的功能需求 – 設計(Design)。
• “Do the right thing (分析)”and “Do the thing right (設計)”。

系統結構分析與設計的手法

• 以組成元素來區分
  • Non Object-based
    • Procedure-based and Data-Oriented
    • Form + Script (Function) + Data-model
  • Object-Oriented
    • Functional Object – 源自於需求(Requirements)
    • Entity(Essential) Object – 源自於領域概念(Domain Concepts)
• 以系統分析的思維來區分
  • Functional-based Decomposition
  • Essential Object-based Decomposition

圖1、Non Object-based Structure

閱讀全文 »

當我希望能快速一窺整體系統的全貌，而將複雜的局部細節封裝(encapsulate)時，我會「大題小作、化繁為簡」。

當我希望將焦點擺在某一局部，並把該局部視為一個整體(whole)，剖開局部探究內部的細節時，我會「小題大作、、化簡為繁」。

溝通時，需要先釐清彼此所討論的主題是擺在「大題小作」上，還是「小題大作」？
免得因為對範圍(Boundary)、層次(Layer)認知上的不同，而雞同鴨講。