每个主题域对应系统有关的业务职责区块。例如医院的体检部，门诊部，住院部，各司其职。
主题域里，我们定义“何人做何事”，叫做事件。真正有价值的事件，则是与待建设系统有交互活动发生的事件。
例如体检中心，日常要做的事件主要有：体检者申请体检，体检者进行体检，客服人员查询体检报告结果，体检者在体检餐厅就餐等。其中体检者在体检餐厅就餐，不需要用到系统，所以我们排除掉此类事件。
剩下的体检者申请体检，体检者进行体检，以及客服人员查询体检报告，都会使用到系统。那么就保留在主题域下面，作为业务建模过程中确定下来的业务事件。
要注意的是，一个事件，应该是具有明确的业务意义的。例如：这里面体检者进行体检申请，我们不能在这个时候，就拆分成，找到体检表，录入体检申请信息，服务中心审核体检单，这样颗粒度的具体操作过程，因为，[为什么，这里要把理论知识再重新组织一下]
另外，当事件和事件之间的关系过于复杂，我们可以利用流程图，或活动图等方式串联起来。而不仅仅只是把它们写下来而已，这也将有助于我们对于各个独立的主体域里面的事件的之间的关系有更清晰的认知。
另外的思考：
[其实这里的思考，还可以是先把多个主题域的事件，利用流程图全部串联起来。找到主题域和主题域之间的关系，同时也找到事件和事件之间的关联关系。然后我们再利用《软件需求最佳实践》运用到的构件图和上下文环境图，重新构建主题域关系，和主题域与事件的上下文关系，这可以通过一个案例串联在一起进行分析，将会提供一个更严谨的主题域和事件关系的分析图，而不是一开始就找主题域关系，因为在看这部分的过程，我一直有的疑惑就是每个主题域发生什么事我们没分析清楚，怎么就可以清晰地先分析主题域之间的关系呢。]