所以我說，那個應用主題呢

既然說後面會做到金流的部分，就先假設情境是收到錢錢後要來記帳吧
所以應用本身就以「記帳」做為主功能吧！

動手之前，想一想

那麼，在開始之前，勢必要對此功能先做一番規畫

以前中途加入過一個專案，就是對於功能沒有足夠的審視了解就直接開工，導致中期不同人在不同功能的疊加之後才發覺最初的規劃或是後來他人的設計會導致功能互相打架。
這其中除了起初沒有規劃之外也包含了協作溝通上的失能，而最後則是整個打掉重練重新溝通才即時做完（汗

由此可見，匆匆下手與缺乏溝通只會徒增困擾，所以今天就來做功能面的發想與基礎資料表規劃

功能面發想

作為記帳應用，又呼應主題逐步做出 MVP 產品，列出了下面幾點

1. 可以做帳務的存入提出
2. 可以做帳本間的轉移
3. 可以擁有自己的帳本

在主要功能後就可以來完成

1. 可以收一點錢錢的金流
2. 可以看酷酷的圖表
3. 觀眾許願

資料表設計

從功能面發想可以接著理解並延伸我們所需要的資料表

帳務的存入提出

最基本的要可以記帳，所以這裡會需要一張表可以處理基本帳務的進出

1. 計數 amount
2. 名稱 name
3. 種類 flow_type 因為預計有收入羽支出兩個部分，打算用 enum 處理

Accounting

帳本間的轉移

要能做轉移，所以需要帳本

Ledger

Accounting 會屬於 Ledger
所以要回頭補 foreign key

Accounting

擁有自己的帳本

重點在「自己的」，意味著也有「別人的」
其實就是 User 啦！

這邊預計使用 Devise 來做 User
因為 Gem 的預設已經滿足基礎需求，所以就不多著墨於表的設計 (偷懶

同樣不能忘記 Ledger 會屬於 User ，所以也要補上

Ledger

這樣就大致完成基本資料表的規劃了（大概

至於酷酷的圖表跟金流的部分，基本不會跟資料表產生資料表上的關聯，所以可以留待實作時候再來做規劃，以目前來說暫時放置應該不會造成影響

今天是完全的紙上談兵，規劃也很簡略，但最起碼對這次整個架構有基本的認識
而且是獨立完成，所以也不存在溝通的問題 XD
往後再根據細節去做調整即可，不需要此時過度的去想像很炫炮的功能或是太複雜的規劃
這樣明天就可以開始動手囉！