✍️
ZiXiang-Blog
  • Jerry Wang Blog
  • 使用 TorchServe 部署 Model
  • How do AppRTC work in WebRTC mechanism ?
  • [系統設計]- 容易產生設計盲點
  • Golang
    • [Golang] Goroutine Concurrency多執行緒淺談
    • [Golang]: 進階用法
    • Golang go mod 入門
    • [Golang] 讓 Goroutine Debug 變得更簡單
  • Security
    • HTTP Token 使用方式: Basic Token v.s Bearer Token
    • 從 RFC 規格書觀點解析 OAuth 2.0
    • 區塊鏈物聯網架構 解決哪些安全性議題?
  • Broker
    • [深入淺出MQTT]: v3.1.1與v5 的差異
    • Broker 到底是什麼?
  • patterns
    • Patterns for Organizing Domain Logic
    • Domain Model: 從無到有規劃新的服務
    • 淺談CQRS
    • Backend System in Microservice Architecture: Where Does data store?
    • Ambassador pattern with Shared Database Pattern
    • Microservice Pattern 犧牲了什麼?
  • K8s
    • 分散式系統: 現代軟體架構與設計考量
    • Kubernetes 超入門
    • Kubernetes 架構
    • K8s 在 DevOps 中的作用
  • Database
    • Relation Database Index Overview
    • Draft: RDBMS(MySQL) v.s NoSQL (Monogo)
    • [淺談]- How Do RDBMS Thread work ?
    • [淺談]-NoSQL資料庫怎麼選?
    • How do pick the database more correctly?
    • Draft: 關聯式資料庫需要知道的幾件事
  • HTTP
    • Overview The WebSocket Mechanism
Powered by GitBook
On this page

Was this helpful?

  1. patterns

Patterns for Organizing Domain Logic

What is a Design Pattern?

Design Pattern 通常需要具備幾個描述要件 Context, Problem, Solution。

  • Context

    • 解釋目前遇到的問題,所以需要提出一個 pattern

  • Problem

    • 描述遇到的問題,所以需要權衡的難點 (Forces),這個難點通常會是有互斥的狀況。

  • Solution

    • 提出的方案,需要平衡難點,通常會需要提出兩個面向

      • 靜態 Relationship

      • Run-time behaviour

Domian Logic Problem Context

Domain Logic 在維護上管理上,需要精準的處理 Business model 需要兼顧軟體的維護性、可理解性、效能以及可測試性。當隨著軟體迭代,維護性、可理解性、效能以及可測試性都會隨著時間越來越複雜。

Problem

  1. 要如何保持低開發成本

  2. 隨著時間產品生命週期越久,所需要開發成本越高

    1. 指的是維護性、可理解性、效能以及可測試性

    2. 開發時間: 測試時間,開發時間,理解程式碼

Solution

從[1] 文獻中,主要有三個 pattern 使用 Transaction Script, Table Moudle, Domain Model,隨著產品的生命週期,可以採用以順序為: Transaction Script -> Table Moudle -> Domain Model 。

  • Transaction Script

Def: Organizes business logic by procedures where each procedure handles a single request from the presentation

Transaction Scripts 不會再細分結構,像是 retrive data, handle request ... 。換句話說,將所有的邏輯封裝在 Object 中。

Static Structure

Dynamic Structure

  • Domain Model

Def: An object model of the domain that incorporates both behavior and data

在 Domain model 中,會明顯區分 Entity Object 與 Value Object。

  1. Entity Object: 可直接對應商業邏輯的 component 並可直接取用 data,具有 identity 的特性 (唯一性)。

  2. Value Object: 是一種裝飾 Entity Object 的一種結構。具備 Comparable 的特性。

在 Domain Model 需要盡可能對應需求的操作

Dynamic Structure

  • Table Moudle

def: A single instance that handles the business logic for all rows in a database table or view.

這一個介於 Domain Model 與 Transaction Script 的一種 Pattern。與 Domain Model 最大的區別在於 Object 沒有 ID 的概念,且沒有特別區別 Object 定義。

Static Structure

Dynamic structure

Conclusion

Pattern
Positive
Negative
Suggestion Scenario

Transaction Scripts

  • 在量體小的feature 是容易理解的

  • 學習難度低

  • 擴充性很差,當要持續維護的時候難度很高,且會有很多重複的程式碼。

  • 一次性的 scripts

Domain Model

  • 貼近 Business Logic

  • 具備好的擴充性

  • 相對於三個 patterns 中最複雜的

  • 學習曲線難度高

  • 長期大型專案

Table Module

  • 具備好的擴充性

  • 學習難度低

  • 複雜度介於中間

  • Object 無法完全貼近真實情境

  • 中長期大型專案

Reference

[1] Fowler, Martin. Patterns of enterprise application architecture. Addison-Wesley, 2012.

PreviousBroker 到底是什麼?NextDomain Model: 從無到有規劃新的服務

Last updated 11 days ago

Was this helpful?

[1] A sense of the relationships between complexity and effort for different domain logic styles.