問題 快的 left 上下文 結構 保持 減少 都是 部分

什麽好的服務？ 松耦合 一個松耦合的服務應該盡可能的少知道與之協作的那些服務的信息。 如果做到了服務之間的松耦合，那麽修改一個服務就不需要修改另一個服務。 使用微服務的特定就是可以獨立的修改和部署單個服務而不需要修改系統的其他部分。 高內聚 把相關的行為聚集在一起，把不相關的行為放在別處。 因為如果改變某個行為的話，最好能夠只在一個地方進行修改，然後就可以盡快的發布。減少部署多個服務的風險。 限界上下文 一個由顯式邊界限定的特定職責。 共享的隱藏模型 例如財務與倉庫兩個獨立的限界上下文，他們都有自己的對外接口；財務不需要知道倉庫的內部細節，但是財務需要知道倉庫的庫存水平用於更新賬戶，為這個這種需求，可以再財務與倉庫之間創建一個庫存項的共享模型。使用共享牟模型可以防止緊耦合的風險。 模塊和服務 邊界內部是相關性比較高的業務功能，從而得到高內聚，這些限界上線文可以很好地形成組合邊界。 模塊邊界可以稱為絕佳的微服務候選，一般來說，微服務應該清晰地和限界上下文保持一致。 過早劃分 過早的劃分微服務會是有問題的，會導致在早期的開發過程中很多的跨服務修改，而這些修改的代價相當高。 將一個已有的代碼庫劃分為微服務要比從頭開始構建微服務簡單的多。 業務功能 當你在思考組織內的限界上下文時，不應該從共享數據的角度來考慮，而是應該從這些上下文能夠提供的功能來考慮。即首先考慮這些上下文時用來做什麽的，在考慮它需要什麽樣的數據。 建模服務時，應該講這些功能作為關鍵操作提供為其協作者（其他服務）。 逐步劃分上下文 可以先識別粗粒度的限界上下文，而這些限界上下文可能又包含一些嵌套的限界上下文。 需要選擇是使用嵌套的方式還是完全分離的方法來定義限界上下文。 傾向於使用嵌套方法的原因是它可以使得架構更成塊從而更好的測試。 使用嵌套方法：如果所有服務都是由一個團隊管理的，那麽嵌套結構會更合理，其原因在於組織架結構和軟件架構會相互影響。

第三章：如何建模服務