Please enable JavaScript.
Coggle requires JavaScript to display documents.
架構 (架構思維 (一切都是為業務服務的 (只有業務架構梳理清楚了，才能去梳理技術架構, 只有業務和技術架構都梳理清楚了，才能去梳理組織架構,…
架構
架構思維
一切都是為業務服務的
只有業務架構梳理清楚了，才能去梳理技術架構
只有業務和技術架構都梳理清楚了，才能去梳理組織架構
組織架構的目的是為了讓業務和技術最好地運作
架構的設計必須先業務，再技術，再組織
許多因素是在做架構時要評估的，尤其是價值、風險、成本
必須考慮到分析、設計、實施的過程
必須估量價值、風險、成本的大小
考慮要有三個面向
技術
業務
組織
架構的實行
先重整組織架構、再重整業務架構、再重整技術架構
組織架構會影響業務架構，業務架構又會影響技術架構
架構師（Architect）
建模（Modeling）
模型（Model）
溝通的工具
對於軟體專案的設計（包括系統設計和架構設計）
有助於設計、實驗、觀察、改進變化過程
模型的變化，就是你對於軟體的重整（重新工程化）的設計
「建立模型」簡稱「建模」
UML
要時時刻刻知道目的是什麼
良好的建模能力，重點在於「去蕪存菁」
記錄和目的相關的要點
只記錄有差異的點
差異是比較出來的
在建模之前，最好先抽象，把一些概念和其擴充出來的類型確定下來
在類型的基礎上建模
抽象（Abstracting）
把「一群事物」集中在一起做比較，再把它們相同的資訊集合起來，這個過程就是抽象（abstraction）
抽象的結果是概念（concept）
可以把概念擴充為類型（type）
類型包含了概念，但比概念多了「對某些關鍵訊息的要求」
某個事物想要屬於某種類型，就必須滿足這個類型的概念
提供這個類型要求的關鍵訊息
「分類」（classification）
要建模的東西「依據某些特質」分成幾類
對「特質」的選擇，靠的也是對目的的理解
可以降低概念和類型的模糊
提升概念和類型的價值
目的是為了更好地抽象
目的是更好地建模
當你試圖把一群概念或類型集合在一起，對它們繼續抽象時，階層（hierarchy）就出現了
好處是重複使用定義
缺點是稍微變複雜
根據使用方式區分模型
資料模型
建模對象通常是真實世界的事物
在執行的過程中會不斷進行基本的新增、刪除、修改，導致模型持續的變化
程式碼模型
通常是開發者腦中的想法（演算法）
可以被執行
通常會關聯到其他的資料模型
在執行的過程中不會改變自己的程式碼模型
可能會改變關聯的資料模型
模型是如何產生
運作的過程中長時間逐漸累積建立的
親自建立
架構的意義
通過各種規劃和設計，盡可能地降低風險