摘要

對於需求有較清楚的概念後，就要開始思考該如何達成需求。針對這次的專案，筆者想初步畫出軟體架構圖，並開始規劃系統中的資料模型。
希望我們可以設計出一個有彈性（嚼勁）的系統架構，能方便擴充修改（愈嚼愈香）。

概念說明

對於需求有較清楚的概念後，就要開始思考該如何達成需求。針對這次的專案，筆者想初步畫出軟體架構圖，並開始規劃系統中的資料模型。

系統架構圖 Deployment Diagram

https://medium.com/bucketing/system-design-系統架構基礎-什麼是系統架構-bed1e1323770

• 用途：描述系統中包含哪些子系統、服務、第三方服務，該如何部署等等，藉由這樣的圖可以畫清系統的分界，增加管理開發的順暢度。
• 常見的網路服務就會包含前端伺服器、後端伺服器、資料庫等三個部分。劃分出來後，就可以個別開發實作，出錯時也比較容易鎖定問題的原因。

資料模型 Data Schema

https://medium.com/bucketing/system-design-系統架構基礎-資料模型-37e62c60e100

• 用途：讓工程師構思資料庫儲存資料的方式，系統逐漸變大的過程中，資料類型也會隨之增多，善用資料模型可以管理好不同資料類型之間的關係，資料庫的效能也可以優化提升。

本日成果

根據前兩天擬定的需求，我們可以規劃出一個網站系統，在專案的第一個階段，我們先實做一個簡單的網站，因此使用Django就綽綽有餘。Django也內建了SQLite 一個輕量的資料庫，因此我們也不需要額外安裝其他的資料庫系統。

系統架構圖 v1

第一個階段，我們可以直接使用 Django 來接受使用者的請求，並直接回傳網頁結果給使用者的瀏覽器，因此我們只需要開發Web這個區塊即可。

淡藍色表示運行軟體服務的機器，綠色表示部署的最小單位，黃色則是服務中的一個模組，因為Django跟SQLite會同時部署，因此放在同一個綠色框框中。

未來引入PostgresSQL、Redis等不同的資料庫，就會用另外一個綠色框包起來，這也是微服務的概念。

資料架構圖 v1

因為美食地點包含餐廳、咖啡廳、麵包店、甜點店、巷口那家店，甚至是不起眼的住宅家，因此物件就用Place來命名。

網站上也要顯示照片，一個地點會不只一張照片，因此建立一個Photo的資料類型，來儲存圖片資訊。

Place 和 Photo 之間也會有關聯，因此需要額外建立一個表格。

成果如下

可以看到Place有許多屬性，後面會加上此屬性的資料型別，常見的有數字、字串等，在資料庫中甚至會需要設定字串的最大長度，不同的資料庫系統可支援的資料型態有些差異，這裡就先使用text 來表示不固定的字串。

而Photo有一個FK(foreign key)，此欄位會儲存一個地點的PK，這樣也表示兩個資料模型是一個1對多的關係，一個地點會有多張照片，一張照片則只能代表一個地點。

Drawio 小技巧

只要把一個圖形的**container**屬性打勾，裡面就可以裝其他圖型，並且可以跟著拖曳囉。

• 參考資料
  1. Draw.io
  2. Draw.io教學
  3. https://namepluto.com/關聯式資料庫的鍵值類型-pkfk-是什麼？/