前面講到了架構師在高層架構設計階段要做的事情，以及基本的方法。
接下來具體地看看如何把設計落地：
首當其沖的就是要確定系統邊界，
下面就來聊一聊確定系統邊界要做什么，以及如何確定系統邊界。
一：確定系統邊界，架構師需要做什么，包含但不限於：
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：確定系統邊界
找到相關系統后，就按照前面講的需要明確的內容，一個一個交互功能點的去細化，把所有的內容都確定好過后，基本上咱們系統的邊界也就確定好了。
差不多到這兒，我們就能確定好系統邊界了，終於邁出了高層架構設計落地的第一步，恭喜恭喜！
有問題或者意見、建議，請評論留言或者私信，大家一起探討，一起進步！
當然，如果你覺得本系列文章還不錯，能夠給你一些啟發和思考的話，請關注、點贊、收藏加轉發，讓更多的朋友加入到我們的行列，謝謝啦！
更多架構師之路干貨文章，已在路上，稍后就到！
