其實真正的垂直架構中沒有絕對的拆分方式。那麼，每個架構師，或者每個公司都有自己的一套體系和方案。只是業內比較出名的幾個企業會針對性的出一些自己的拆分方案， 因為它們比較知名，所以在行業內部就有相應的所謂規範的東西，

那麼在實際，開發過程中，我們如何對一個大的系統進行拆分？我個人認為主要包含以下幾個方面

第一方面，單元的可複用性，也就是說，在我們開發過程中，如果有某個服務需要進行隔離拆分，那麼這個模組最好是能夠進行重複使用的，並且對於更多的系統都可以提供服務，

第二方面，服務的可用性，最初從單體架構演變成分散式架構的原因就是為了避免某個模組，因為一些不可預知的錯誤或異常導致整個系統無法正常執行，所以在拆分過程中，我們可以按照此原則進行拆分，排除有可能發生錯誤或者容易發生錯誤的，非重要性服務，

第三方面，個人意識的劃分，或者也稱為整個專案流程的劃分，按照整個專案執行週期過程中所有參與此專案的模組服務進行劃分，比如我們所說的商城系統，那麼它將有對應的商城物流訂單支付通知回撥等各種系統組合而成，這樣劃分的形式比較明確，按照整個專案執行過程中生命週期內各個階段或者各個服務較，明顯拆分

第四方面，按照專案複雜性進行拆分，專案下一單元的單位為系統，系統的細化單元為服務介面，按照服務介面的不同型別，可以進行進一步的專案劃分，比如我們所說的支付系統，那麼支付系統中又包含了支付介面回撥介面，我們的扣帳介面呼叫第三方支付的介面等等，這一系列的服務操作，而這些服務的操作，我們又可以具體細分為單元，所以在很多第三方支付公司或者電商平臺中，我們又可以將整個支付系統拆分為賬單系統賬戶系統賬戶系統，支付此係統，訂單系統等等

當然，如上所述都是個人觀點，每個工程師在進行開發過程中都可以按照自己的行為標準去進行專案的服務拆分，只要能夠保證在服務拆分之後，服務之間的呼叫存在著較為完整的安全性，穩定性便可以進行拆分