前面幾天跟大家分享如何把 DDD 的戰略設計導入到 Laravel 專案中，然而戰略設計只是 DDD 的一部分而已，雖然導入這個部分對專案就有不錯的幫助，但還是要多看一些書或是其他大大的分享，才能理解的更透徹。

只導入戰略設計的 DDD ，又稱 DDD Lite。

有了 DDD 的概念之後，我們對於各種問題要如何拆分問題空間與解決空間已經比較有概念，然而實作上要考慮到的當然不只是讓功能可以跑而已，在應用程式規模不斷擴大、服務用戶不斷提升的時候，我們要更認真的思考一些問題：

• 安全
• 穩定
• 效能

安全

在我開始這次鐵人賽的一開始就一定有提到安全性這件事，安全性其實是一種習慣：習慣不要暴露敏感資料、習慣驗證用戶所提供的資料、習慣驗證用戶權限、習慣把不必要對外公開的服務藏起來、習慣慎重選擇依賴的套件或工具.....，養成良好習慣就是實現系統安全的第一步。

穩定

想像你使用一個應用程式，每次使用的時候都會遇到很多 Bug，這樣情況是令人沮喪的，不管是對使用者還是開發者都一樣。

雖然軟體本身是不可能做到 0 bug ，但我們應盡量地去檢查可能出現的 bug。然而每次上線前都把應用程式中的每個功能去跑過一遍那是不可能的，因為現在不僅軟體版本迭帶速度很快、軟體通常也很大，手動測試所有功能是不切實際的想法。

這就是為什麼我們需要 自動化測試，它沒辦法幫我們解決 Bug，但它可以快速的告訴開發人員那些地方現在出了問題，幫助我們快速解決問題，提高系統穩定性，使版本發佈更有信心。

效能

當系統資料越來越龐大時，效能的問題就越有可能突出，舉例來說：1千筆資料在處理的時候，或許還可以一次把它讀進記憶體中一次處裡，但資料如果放大一千一萬倍甚至更多時，這樣的作法很容易使系統壞掉，因此在處理批量資料時，應該是要有策略的把資料一塊一塊處理；相對的，儲存資料的時候也是一樣，不要使用迴圈一筆一筆地把資料寫進資料庫，如果有批量資料須要進到資料庫，那應該優先考慮一次寫數筆進去以減少資料庫壓力。

此外，一個成熟的架構應該要對不同的場景選擇不同存取策略，例如配合使用 NoSql、Redis、Message Queue 等服務，將職責分配在較合適的服務上才是明智的。

流量處理方面，可以學習像是 aws 的 Lambda、CloudFront、Auto Scaling、Load Balancer來提升伺服器的附載能力。

軟體開發過程中應該要總是考慮到效能，但任務被正確的執行才是最重要的。