CI/CD 討論過後，該來看看程式架構的部分了。
我們來談談怎麼用 Laravel 作出難以維護的 monolith 架構。
多數的專案，都是由一個小專案開始，可能這個專案只有幾個功能，像是提供用戶登入註冊，買賣東西……等。
隨著專案成長，客戶的數量以及需求越來越多，專案的功能也會越來越多。久而久之，專案的功能相互關聯，每調整其中一個地方，都要看大量的程式碼才行，修改之後還有大量的檢查要做。這個專案難以維護的程度會越來越高，變得如同一塊磐石（monolith）一樣。
要是專案的文件不完整，導致有的功能只能透過老員工的口耳相傳，來知道功能的規則是什麼的話，那就更難以維護了。
monolith 架構是一個會隨著時間越來越難維護的架構。有時我們什麼都不用做，只要保證這個專案隨著時間成長時，沒有人提出任何調整架構的建議，專案就可以越來越難維護了。
如果功能需要的資料來源很多，與其和其他的系統透過 API 溝通，可以和資料庫的擁有者溝通，直接存取資料庫。
這會導致這個專案的調整，會需要看所有相關的資料庫結構，才可以知道怎麼調整，提升專案的維護難度。
還可以保證相關資料庫的異動，都可能需要調整這個專案，進而提升和這個專案相關資料庫的調整難度。
要讓 monolith 架構的專案更難維護一點，我們就要確認沒有人幫他建立說明文件。
這樣一來，要維護的人只能從大量的程式碼裡面找修改的地方，或者從老員工（有時是已經離職的員工）問出怎麼調整，大大的提高維護的難度
iThome鐵人賽
看影片追技術