從架構到設計 - 重新思考 Rails 架構
不論是資料驅動(Data-Driven)還是領域驅動(Domain-Driven)的角度,思考的範圍仍侷限在單一功能,如果要討論一個完整系統,就需要再繼續往上提升層級到架構(Architecture)的角度進行思考。
架構問題對於完整的領域驅動設計(Domain-Driven Design)仍屬於戰術(Tactical)問題,也就是開始實踐的部分,還需要再往上思考策略(Strategic)問題,關於軟體的目的的思考。
策略
我認為在討論架構之前,還是需要從「策略」出發,假設我們給了錯誤的策略,那麼後續的戰術(架構、設計)都可能會是錯誤的。
然而,針對領域驅動設計中策略的討論並不好找到學習資源。原因在於這些策略大多是根據商業需求分析得來,比起找到一個「標準做法」更需要的是深入分析的能力。以常見的事件風暴(Event Storming)為例子,就會將所有利害關係人(使用者、產品經理、工程師)找出來一起腦力激盪,釐清系統的脈絡。
如果要用很粗略的角度去看待這個問題,就是我們該如何釐清使用者對於產品的需求,這一點在不同的理論(如:敏捷開發)也都是一樣的,如何有系統的進行,就可以使用上述提到的工具來釐清。
同樣的,既然是策略層級的問題,也需要對齊公司的目標、願景,並以更全面的方式看待,而不是只在某個功能、產品、部門層級去判斷。
架構
當我們決定策略後,大致上會知道系統開發追求的目標是什麼(快速更新、穩定等等)在選擇技術的搭配上就會明確很多,那麼架構就會相對容易的成形。
舉例來說,假設公司未來的重點是放在發展人工智慧(AI)相關的應用,並且要自己訓練模型提供 RESTful API 服務,以追求穩定的企業客戶為主。在這樣的前提下,對於架構的選擇就會偏向能夠處理大量資料的資料庫、容易搭建 RESTful API 的框架等等條件。
直到這些議題被確定下來,我們才能夠正式進入到軟體層面的架構議題。當我們選擇了 Rails 框架作為開發工具,背後有怎樣隱藏的意義呢?
舉例來說,入門 Rails 框架並不困難且容易修改、擴充,但是對於過於複雜的系統就沒辦法很好的處理,因此很適合需要快速開發提供高度客製化選項,但是對功能需求不複雜的情況,因此 Rails 一直都接案公司偏好的框架之一。
然而,每個系統都會變複雜、擴大,後續就會需要討論替換掉 Rails 或者設計更複雜的機制、架構來處理這些問題。
以 DHH 所在的 37signals 來說,產品複雜度都是有意控制在某個規模下,因此 Rails 一直可以適用,但是其他像是 Twitter、Shopify 等就不一定,最後發展出更換語言、多語言混用等等不同的方式。
設計
架構跟設計很像,到底差在哪裡呢?我在 2023 年的 RubyConf TW 演講 用細節程度來作為區分。這是因為在討論架構時,我們通常是用大分類、設計模式等方式討論,然而在撰寫系統設計(System Design)文件時,則會詳細的把介面、流程圖、資料庫等等詳細的定義。
即使如此,設計這一個概念仍是抽象的。剛好在 2024 年初我看了 Food & Design 這部紀錄片,最開始的時候提到「設計不是產出(Outcome)而是過程(Process)」很適合用來解釋我們在進行系統設計該做的任務。
跟設計師在進行設計一樣,我們透過設計的過程,去探索軟體的使用者如何使用這個系統,並思考如何讓使用者在過程中是流暢的。那麼,要實踐這樣的過程,就會發現從策略的制定、架構的選擇到設計的細節,都會息息相關。
如果對這篇文章有興趣,可以透過以下連結繼續閱讀這系列的其他文章。
- 軟體架構的挑戰 - 重新思考 Rails 架構
- 資料驅動設計 - 重新思考 Rails 架構
- 複雜的操作 - 重新思考 Rails 架構
- 時區換算 - 重新思考 Rails 架構
- 報表機制 - 重新思考 Rails 架構
- 通用化功能 - 重新思考 Rails 架構
- ActiveRecord 的限制 - 重新思考 Rails 架構
- 領域驅動設計 - 重新思考 Rails 架構
- 從架構到設計 - 重新思考 Rails 架構
- 重復使用的反思 - 重新思考 Rails 架構
- 釐清脈絡 - 重新思考 Rails 架構
- 劃分邊界 - 重新思考 Rails 架構
- 職責劃分 - 重新思考 Rails 架構
- 架構規劃 - 重新思考 Rails 架構
- 驗收測試 - 重新思考 Rails 架構
- Controller - 重新思考 Rails 架構
- Form - 重新思考 Rails 架構
- Use Case - 重新思考 Rails 架構
- Entity - 重新思考 Rails 架構