軟體架構設計原則：導論

我說明一下，為什麼會有這篇文章？因為最近，我正在籌備一個全新的課程，這門課算是我多年來在企業端顧問 + 也包括帶團隊做專案，也包含了幾次替企業客製化 API Framework 框架的相關實作經驗的體現。

記得，好幾年前我分享過一堂關於【您的軟體架構構敏捷嗎？】的課程，這堂課程其實就是在告訴你，實務上進行開發時，沒有什麼開發的需求得要完全的想清楚、完全得清楚該怎麼做 + 或者是得完全的分析清楚後，才能進行程式碼的開發與撰寫。在敏捷的環境裡面，你沒有一項任務是進行所謂的軟體架構設計，但是你卻還是得進行當下適當的架構設計，這其實還蠻抽象的，但是你不應該在這個抽象預想、或者設計太多未來不太會用到、或者是根本不會用到的抽象設計在裡面，因為太多的設計一部分也又回到瀑布式的時代，難道你得全部分析完，才能開始寫程式？

但.. 最近我也有篇文章【為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？】說明，撰寫程式之前，還是先做個簡單的分析比較好？所以，那到底，我一開始要分析，還是不分析呢？答案是：你要做基本的抽象分析，但是只是做應該做的部分，什麼是目前應該做的部分？這其實需要蠻多相關的經驗，也沒有實際的標準答案，方早在與蔡煥麟老師互動時【FB 連結：https://www.facebook.com/share/p/PdntjirACrAvVhmw/】，我腦袋也迸出許多這些年來的設計與經驗感想出來 XD

圖（一）、DDD 戰術建模 - 建置 API 服務

通常，我們在進行系統開發時，會進行部分抽象的設計，在敏捷裡，我們可能會以價值為最優先考量來進行設計，但這個設計裡面，我非常喜歡 DDD 的 Core Domain 的概念，我不講過多的技術、也不希望有過多的平台設計或者框架的影子在裡面，我只希望先 Focus 在這個領域 (Domain) 裡面就好，因此，在藉由 Clean Architecture 的 Plug-In 的架構裡，我就可以先避免掉其他無用的抽象設計，也因此可以幾乎避免掉爾後的疊床架屋的設計出現。

圖（二）、先前小弟一堂課【利用物件導向五大設計原則 S.O.L.I.D. 來建立強固的軟體系統】的部分截圖

在不久前，約今年初，我也在企業授一堂課，關於透過 SOLID 建構六角架構的課程，這一堂課的主要內容其實也不是在講述 SOLID 有多麼神奇，更不是強調遵循著它，你一開始設計系統就完全不會發生增加了三四五六七個功能之後，還不會影響到原有的程式，雖然你的最終設計會基於它，但你可以在增加三四五六七功能時，將目前的專案以這個目標進行重構。

補充：

• 關於 YAGIN (You aren't gonna need it!) 原則： 我不常談 YAGIN 原則，不過我以前提到的敏捷的軟體架構設計其實重點就在於 YAGIN 原則，沒有過多的預先設計，因此沒有什麼需要將架構拉出來後，才能撰寫程式的情況出現，過多的預先設計最終可能變成無用的程式碼，而變成系統的包袱，要知道，一個專案內的每一行程式碼都是有成本的。

• 關於 KISS (Keep It Simple & Stupid) 原則： 我也未曾提過 KISS，不過在了解了 KISS 後，發現事實上在我累積了 20 多年的軟體專案的實作經驗後早就告訴我，不要在專案裡使用大部分 Team Members 不懂或不熟悉的技術，那只是徒增麻煩或是增加維護 & 溝通成本而已。對於有 Deadline 的軟體專案來說，並無實質的好處，因為都只是解決了相同的問題而已。

關於跨平台的 Web API Framework 框架開發_V2

跨平台的 Web API 框架設計的 (第二版) 的課程裡面，我會以框架設計為出發點，講授一套與領域無關的框架設計方法，因為設計框架目的是讓開發變得簡便，但是又不希望因為這個框架使的系統產生諸多的限制。在這個課程當中，您可以學習到一套從六角架構為出發點，來探討與設計一套堪用的框架技巧，你可以試著去擴充它，擴充你想要的 Infrastructure，這裡就會使用到 SOLID 的 ISP 與 OCP 等原則，當然了，這裡有部分可能會違反上面提及的 YAGIN 原則，因為這裡使用了 OCP 原則，所有的專案都使用這個 NuGet Packages/Library ，所以也許 100 個專案有 10 個專案會使用到 A 功能、另外 30 個專案又會使用到 B 功能，而 A 功能不見得剩下的 70 個專案會使用，但你可能還是得預先設計，所以這是非常有可能的。

只不過，本課程會以一個 Core Domain 為基底，來設計我們這個堪用的框架。

後記：

這些年來的分享，如果跳著看，好像又要馬兒好、又要馬兒不吃草？這怎麼可能呢！？但是仔細想想這些年來，我們所做過的軟體系統，目標無不是希望最小化建置和維護『需求系統』所需要的人力資源，唯有這樣，公司才有可能會賺錢。所以，成本要最低，是壁只做目前這個 Core Domain 下應該要做的事情就好，目前只須要維護的功能，能支撐的住的架構即可，但.. 也不是完全不設計。