中年大叔的鹹魚翻身作戰計畫已經進入第 9 天了，基本上已經學會了如何建立 Xamarin.Forms 行動應用程式專案，以及將專案編譯並分別部署到 Android、iOS、Windows 等三種主要作業平台的模擬器上執行，在接著進一步學習之前，有需要再度回顧一下這次主要學習目的，確認要開發的應用程式的類型。
對的！我們想要學習的不是獨立於各自手機（或平板）的程式，而是資訊可以對外流通，用於管理各種商業行為的商業應用程式，所以在行動裝置的程式之外，還需要有一個獨立在外的資料庫（例如 Azure SQL）用以儲存操作過程中所產生的資料。一般來講，除了安全性的理由之外，個別的手機是無法《直接》連接外部的資料庫進行資料存取動作，所以手機與資料庫之間還要夾著幾個操作區塊才可以，今天就來探討該如何依各操作區塊的功能面來規畫方案的架構。
方案總管
如前所述，要完成整體的行動商業應用程式功能，需要有幾個部分的功能區塊相互合作來完成，一般在程式設計時會將該相關功能用專案（Project）區分，好幾個專案再用一個方案（Solution）管理。因此，首先新增一個空白的方案來總管底下的專案。阿源哥哥習慣以應用程式所要達成的功能（或解決的問題）取一個相關的名字。比如果想開發一個叫外送的 App：
外送的日文叫做「出前（でまえ）」羅馬拚音為：「de ma e」。
領域物件
我們想要開發的應用程式是用來解決某項商業上的問題，也就是說某個領域（Domain）的問題，而一般會用程式語言所說的類別（Class）來定義某項商業行為要用哪些數值模型來表現，比如說，客人了點了一趟外送的服務，商家所要得到的資訊可能需要包括：訂購日期、訂購者姓名（至少也該有個王先生、李小姐之類的）、希望送達日期時間、送達地址、訂購商品內容、價錢 ...... 等資料，而將這些資料邏輯性的組合成一個一個的類別，而各個類別間設立關聯，這些類別稱為領域物件（Domain Object）也有人稱為商業物件（Business Object）。
因為這個專案是與領域問題有關，所以阿源哥哥習慣是在方案名稱之後加 .Domain 來當作專案名稱。請留意，因為我們希望這些領域物件可以跨平台使用，所以記得選擇 .NET Standard 的類別庫專案範本：
資料存取
商業行為所產生的資料必需儲存到資料庫以備往後的查詢與統計之用，這些如何與料庫連線，如何將資料與資料表（Data Table）對應，如何將資料在資料庫中：新增、修改、刪除、查詢 ..... 等功能可集中在一個專案中設計。
因為這個專案與資料（Data）有關，所以阿源哥哥習慣是在方案名稱之後加 .Data 來當作專案名稱。請留意，因為我們希望這些資料存取功能可以跨平台使用，所以也是記得選擇 .NET Standard 的類別庫專案範本：
RESTful APIs
因為行動裝置應用程式無法直接與遠端資料庫連線進行資料存取的動作，而目前的業界主流是透過依循 REST（Representational state transfer）原則所設定的 Web API 進行溝通。因為這個專案與 Web API 有關，所以阿源哥哥習慣在方案名稱之後加 .WebApi 做為專案名稱，使用 .NET Core 的 ASP.NET Core Web 應用程式專案範本的 Web API 進行實作：
使用者介面
最後就是實際擔任讓使用者操作應用程式使用的使用者介面專案，前幾天已經體驗過一次了，依習慣的命名原則（讀者不見得一定要遵守）在方案名稱之後加 .MobileApp 為專案名稱：
所建立出來所有方案總管下的專案架構如下：
因為實際部署到行動裝置的三個 .Droid、.iOS、.UWP 應用程式專案，除非有需要加入屬於各平台專用的程式碼之外，才會在該各別專案內加入程式碼。一般在開發過程中很少會去留意這些專案，所以阿源哥哥習慣會用一個方案資料夾來放置這些專案，平常就隱藏在方案資料夾內，讓整個方案總管的內容看起來比較清爽一點：
新增好方案資料夾並命名之後，就可以按住滑鼠左鍵將該些方案拖拉到方案資料夾之內：
好吧！今天就學習到這裡，明天再繼續了。
