＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊
傳統且比較直觀的開發方式係採以表單 (form)畫面為單位、然後連結資料庫直接存取資料，這是屬於相當典型的 Client/Server 2-tier 開發模式。
即使轉移到 Web 採所謂廠商提供的 Web MVC 框架 (如 Java Spring MVC)，但那也只是 Web 端的一種技術解決方案 (解決 Web Page 狀態控管問題)；然後再使用廠商提供如 Java Spring O-R Mapping 機制 (如使用 Hibernate Framework)連結資料庫，這仍是傳統的 Client/Server，重視以資料為導向 (data-oriented)的開發方式。
「資料導向」的開發方式直覺且簡單，當系統規模小且營運需求並不常變動，這樣是行得通的，而且在系統開發的初期會是相當快速的；但當營運規模大得經常會要求系統快速配合商務運作，「資料導向」的開發模式卻往往耗在所謂的「共用性整合」議題上太多等待時間了，那種有著「剪不斷、理還亂」的感覺，不僅讓人苦惱，也是引起紛爭的主要來源。
事實上，「資料導向」實際上早已悖離了軟體開發的第一個最基本原則：「封裝 (encapsulation)」。過早揭露資料與邏輯的細節，而使得系統的複雜度提升。
採以「使用案例 (use case)」搭配 Enterprise MVC，則是屬於「服務導向 (service-oriented)」的開發模式。
每一個使用案例代表的是使用者對系統的一種期望 (expectation)，反之系統就是需要履行可以達成使用者的目標 (goal)。從系統分析的角度而言，這就是一種 「系統功能 (system function)」的分解方式。
每一個系統功能，有它內部需處理的「程序 (procedure)」，反映在使用案例就是需求陳述，從其中找出系統要做的「事」。再來才是針對這些「事 (程序)」實作需要處理的邏輯以及相關資料的存取。
可以發現到，「服務導向」是先釐清大功能 (使用案例)需達成的目標 (goal)，再分析需要幾個「程序」才能達成，然後才是談及資料處理的細節。
這也正與人性相符合，「成功學」其中探究的「目標導向」，正是先釐清目標，規劃幾個小目標 (objective)，然後再逐一克服過程中的細節，而非一開始就窮究這些細節，而反而導致遭遇困難卻不知變通而停滯不前了。
「服務導向」反映在軟體系統的實作，最佳的搭配就是 Enterprise MVC (Model-View-Control) 框架。
每一個使用案例搭配一個位於中間層的控制物件 (controller)，並從需求陳述找出需達成該使用案例的程序，也就是「方法 (method)」，如此可以定義出該控制類別的骨架 (skeleton)。
每一個方法的實作，需要邏輯運算或者存取資料，均可以先落實在控制類別內的程式實作。先把原來可能會分散於 UI 與資料庫的邏輯先全抽離出來，集中到中間層，讓 UI 只專注於「展示 (present)」、資料庫只負責資料的儲存。這種有別於 Client/Server 框架的方式稱為 3-tier (Client/Middleware/Database)責任分權的框架。
3-tier 其實也可以視為就是一種 「大」 的結構設計：先區分出 UI、Middleware、與資料庫系統各自應擔負的責任 (responsibility)。
每一個大塊的結構再各自探究內部的組件 (part)，並再逐層細分這些組件更細的責任。如此層次分明，責任明確，系統才不致雜亂無章，因而也得以增進系統彈性/延展性、讓開發與系統維護更有效率，進而提昇系統的再利用性價值。