在單體應用時代，我們是非常重視數據庫的設計的，因為只有正在運行的數據庫和程序反應了業務事實。所以當我們需要了解一個系統的業務時，如果沒有數據庫表設計文檔，可以想象系統維護升級如同一場災難。

在DDD中，我們也有與之向對應的東西：實體。但在考慮和設計實體時，是不考慮其如何存儲的，所以在我看來實體和庫表設計很像，但又不是一回事：比如庫表設計考慮關聯關系，實體雖然也考慮，但這個不是特別重要，我個人認為考慮實體要考慮這個實體的歸屬，即設計實體一定是基于領域劃分之內的，也就是說這個實體設計時，你應該考慮由哪一個限界上下文來維護其 生老病死，這才是重中之重。

那我們先來解釋什么是限界上下文？

限界上下文可以通俗的講就是你的微服務中的一個微服務。上一篇我們的確劃分了領域，但領域并不等同于微服務。在一個領域內，有眾多的實體對象，那么這些實體對象的出生，更新，到最后的死亡，都應該只和一個界限上下文有關。比如訂單這個實體，那么創建這個訂單，更新這個訂單的狀態，更新這個訂單的信息等等操作應該都是一個限界上下文來操作（訂單或交易中心）負責，界限上下文是為相應的實體對象而存在的。

在這個限界上下文中，我們擁有了實體，但實體一定有對應的變化場景：更新，狀態變化，信息更新，刪除等等，那么對應的這些變化一定有對應的命令來觸發。只是這個命令不是一個技術名詞，而是一個業務動作而已，所以命令是伴隨者實體而生的。

當我們搞清楚了實體（由對應的限界上下文維護生命周期和屬性更新），那么我們就可以開始通過用例分析來歸類相應的界限上下文的應具有的功能接口清單，從基于前面已經有的用例分析，我們可以找到其中的有關實體和對應的命令：比如上面的對賬批次，損益單，對賬文件等等；相關的命令有：審核，生成，調整，錄入等等。

通過以上的分析，我們大概可以形成這樣的一個具備可讀性（業務人員，產品人員，技術人員）文檔

而且將所有限界上下文用例文檔合并起來，應該是包含了該系統的所有的用例的。

這個表中的的一項“輸出事件”是由技術和業務 來擬定（后續會再領出來講），主要是通知其他上下文告知已經完成了某個動作，做為其觸發的依據。此文檔一定是所有的參與人員都能讀懂的。