# \[系統設計]- 容易產生設計盲點

### 錯誤：用越多 Pattern 就越猛

正確的設計: **理應是設計出一個不是最差的架構，而不是要試圖設計一個最好的架構 (Never shoot for the best architecture, but rather the least worst architecture)**。

在工作上時常會遇到 JR. 工程師剛上工就想要導入各種系統設計，但往往都無法被接受。原因通常不外乎是沒有延續本來系統的架構為理由，缺乏一制性等等。

***要避免這種狀況，會有三個考慮的準則：***

1. 對於實際 feature 無關的考量特徵:

   指一些明確的設計特徵，像是 “效能，擴充性...” ，且通常會載明載 Spec 中
2. 會直接影響到系統架構的考量特徵:

   指的是一些隱含式考量特徵，但這些不一定會被載明 spec 中，像是 安全性
3. 達成系統運行

   這一類型是實際撰寫系統採用的設計，但原則上架構越簡單越好，只包含必要的架構

實際操作的時候，應該參考下列流程：

Read Requirements -> Extract needs characteristics -> pick must do characteristics

* Read Requirements
  * 閱讀 Feature Requirements(實際商業需求) / non-feature (實際技術需求) 的需求，也或許可以產出隱含的需求。

    ex:  non-feature 需求是像是 performance 等, 隱含需求像是 security 等等的
* Extract needs characteristics
  * 除了要達到商業的目的之外，以及明確的需求之外，隱含的需求未必都要實作
* pick must do characteristics

**常用的系統Characteristics**

| System Domain Concern    | Architecture characteristics                                                              |
| ------------------------ | ----------------------------------------------------------------------------------------- |
| Mergers and acquisitions | Interoperability, scalability, adaptability, extensibility                                |
| Time to market           | Agility, testability, deployability                                                       |
| User satisfaction        | Performance, availability, fault tolerance, testability, deployability, agility, security |
| Competitive advantage    | Agility, testability, deployability, scalability, availability, fault tolerance           |
| Time and budget          | Simplicity, feasibility                                                                   |

### Reference

\[1] Fundamentals of Software Architecture: An Engineering Approach, Mark Richards & Neal Ford