這篇文章一個很重要的觀點是，業務目標催生技術，而進一步演化產生架構。這種看法與自頂向下的設計模型是有區別的，更符合真實世界的對映。

這與極限程式設計的觀點也很像，在業務需求的驅動下，使用一定技術著手實現，然後不斷重構，迭代設計，產生架構。

這裡從簡單來看技術實現目標，架構是粘合劑，架構把技術組合起來解決問題，不過我覺得僅僅這裡理解還太膚淺了些，我理解架構包含幾個層次

1. 需求分析

    1.1  依照業務目標，提取業務需求。

    1.2  依照業務需求劃定業務範圍，繪製上下文圖，明確專案邊界。

    1.3  對核心業務流程建模

    1.4  繪製用例圖和用例規約，明確使用者需求和行為需求。

2. 領域建模

    基於需求對核心概念建模，這部分應包含類圖、狀態圖等

3. 技術選型

    基於業務目標，選擇合適的開發框架、工具和語言等，並大致確定執行環境，比如是否要支援分散式，叢集等等。

4. 概要設計

    對核心需求進行概要設計，得到魯棒圖、序列圖等

5. 分層和分模組

    對系統進行分層設計，比如劃分檢視、服務、持久層。分模組則是把大系統劃分為各個小系統，甚至是微服務，比如使用者管理是一個獨立的模組，資料匯入也可以是一個獨立的模組。細分模組的好處是可以理清各個模組的關係，整個軟體的結構更清晰，更容易維護。

架構要考慮的東西還是很多的，不過我比較認同敏捷的觀點，先基於核心業務按上面的過程大致架構，不必太細，然後不斷迭代和重構。