前面講到了架構師在高層架構設計階段要做的事情，以及基本的方法。
接下來具體地看看如何把設計落地：
首當其衝的就是要確定系統邊界，
下面就來聊一聊確定系統邊界要做什麼，以及如何確定系統邊界。
一：確定系統邊界，架構師需要做什麼，包含但不限於：
1：明確系統該做什麼，而不做什麼
這個非常重要，清晰的邊界，有助於整個系統的架構設計和開發實現，能更好地幫助我們達成軟體建設的目標。
比如我們的系統，只需要做到下完訂單過後生成出貨單，後續的業務就不需要我們的系統來處理了，可能就是推送出貨單到ERP或WMS（倉儲管理系統）等第三方系統就可以了。
那我們就不能瞎做，把出貨單後面的業務也做了，美其名曰業務閉環，胡做一通，該做的沒做好，不該做的做了一大堆，浪費人力、物力、財力和時間。
這就是說，我們必須明確的知道，系統該做什麼，而不做什麼。
2：明確系統與周邊系統的關係
系統與周邊系統的關係，指的就是我們的系統和相關的第三方系統，相互呼叫、互動的關係。
比如上面提到的例子，我們的系統負責生成出貨單，然後推送ERP，那麼ERP就要有相應的介面，並且給出資料結構的要求，也就是說我們生成的出貨單，裡面需要哪些資料，要組織成什麼形式，都是由ERP來決定的。
同樣，呼叫ERP介面過後，我們需要獲取返回的結果，一種是同步等待，另一種是非同步獲取，那我們就需要提供非同步回撥的介面，並規定好需要返回哪些資料，以及資料的組織形式，這個是由我們系統來決定的。
我們的系統並不是孤立的，可能只是大業務場景中的一個環節，必然要和其它相關係統進行互動，否則很多業務也就無法完成了。
所以，我們系統和所有協作完成業務的第三方系統，之間的這種互動關係，是一定要明確出來的。
3：明確系統在整個大業務場景下的定位
這個就是要理解，在使用者整個業務場景中，我們的系統，承載的是那一部分。
客戶的業務，可能有生產的、設計的、製造的、銷售的、客服的、物流的、財務的等等大業務場景。
我們做的系統，假設是電商系統，那麼實際上做的就是銷售這個大業務場景裡面的一部分，那麼這裡面就不會涉及什麼生產、設計、製造等業務。
就算在銷售這個大業務場景，可能我們做的也只是其中的一部分，比如客戶的銷售又分成線上銷售和線下銷售，線上又有to B的、to C的、B2B平臺銷售等等的，而我們可能只是做了其中to B的部分。
大家可以看到，明確系統到底在哪個大業務場景下，具體承載哪部分功能，對於我們理解系統的業務，明確系統的邊界，都是非常有幫助的。
4：明確系統的執行環境以及前置條件
我們需要知道，未來我們的系統執行在什麼環境下，比如：部署環境、伺服器多少、軟硬體情況、網路頻寬的多少、其它配備的資源的多少等。
這直接影響到我們架構設計的選型，還有對質量約束中的一些關鍵元素的達成，比如效能、穩定性等等。
另外，我們還需要知道，要讓我們的系統正常執行起來，需要哪些系統，因為我們的系統只是整個大業務場景中的一部分，需要從第三方系統去獲取一些資料，也需要把一些資料傳遞給第三方系統，否則業務是無法完成的。
因此，我們需要明確系統的執行環境以及前置條件。
5：明確系統與相關係統的互動：
（1）互動方式
是同步呼叫還是非同步呼叫，是我們去呼叫相關係統，還是相關係統調回來。
同步方式是採用資料庫同步，或者是採取非同步訊息同步，還是採用OpenAPI的形式等。
這些互動的方式都要明確下來。
（2）互動頻次
多長時間互動一次，有些可能是實時互動，有些可能是定時互動，比如一天互動一次等，這些都要明確下來。
（3）互動資料量
每次互動，大概會有多大的資料量，最大資料量可能是多少，需要進行壓縮、加解密等處理嗎，這些也是要明確的，這對架構設計是有影響的。
（4）互動限制和約束
跟其它系統互動，有沒有什麼限制，比如一分鐘最多互動次數，最大傳輸的資料量，每次互動處理最長的時間等，這些也是會影響到架構設計的，都需要確定下來。
二：如何確定系統邊界
1：首先是找到相關係統
這個相對比較簡單，在需求調研或需求分析的時候，通過分析業務功能的實現，以及涉及的資料來源和去向，就能容易地找到相關係統。
2：確定系統邊界
找到相關係統後，就按照前面講的需要明確的內容，一個一個互動功能點的去細化，把所有的內容都確定好過後，基本上我們們系統的邊界也就確定好了。
差不多到這兒，我們就能確定好系統邊界了，終於邁出了高層架構設計落地的第一步，恭喜恭喜！
有問題或者意見、建議，請評論留言或者私信，大家一起探討，一起進步！
當然，如果你覺得本系列文章還不錯，能夠給你一些啟發和思考的話，請關注、點贊、收藏加轉發，讓更多的朋友加入到我們的行列，謝謝啦！
更多架構師之路乾貨文章，已在路上，稍後就到！