每個主題域對應系統有關的業務職責區塊。例如醫院的體檢部，門診部，住院部，各司其職。
主題域裏，我們定義“何人做何事”，叫做事件。真正有價值的事件，則是與待建設系統有交互活動發生的事件。
例如體檢中心，日常要做的事件主要有：體檢者申請體檢，體檢者進行體檢，客服人員查詢體檢報告結果，體檢者在體檢餐廳就餐等。其中體檢者在體檢餐廳就餐，不需要用到系統，所以我們排除掉此類事件。
剩下的體檢者申請體檢，體檢者進行體檢，以及客服人員查詢體檢報告，都會使用到系統。那麼就保留在主題域下面，作爲業務建模過程中確定下來的業務事件。
要注意的是，一個事件，應該是具有明確的業務意義的。例如：這裏面體檢者進行體檢申請，我們不能在這個時候，就拆分成，找到體檢表，錄入體檢申請信息，服務中心審覈體檢單，這樣顆粒度的具體操作過程，因爲，[爲什麼，這裏要把理論知識再重新組織一下]
另外，當事件和事件之間的關係過於複雜，我們可以利用流程圖，或活動圖等方式串聯起來。而不僅僅只是把它們寫下來而已，這也將有助於我們對於各個獨立的主體域裏面的事件的之間的關係有更清晰的認知。
另外的思考：
[其實這裏的思考，還可以是先把多個主題域的事件，利用流程圖全部串聯起來。找到主題域和主題域之間的關係，同時也找到事件和事件之間的關聯關係。然後我們再利用《軟件需求最佳實踐》運用到的構件圖和上下文環境圖，重新構建主題域關係，和主題域與事件的上下文關係，這可以通過一個案例串聯在一起進行分析，將會提供一個更嚴謹的主題域和事件關係的分析圖，而不是一開始就找主題域關係，因爲在看這部分的過程，我一直有的疑惑就是每個主題域發生什麼事我們沒分析清楚，怎麼就可以清晰地先分析主題域之間的關係呢。]