遵循系统分层架构与菱形对称架构对代码模型的约束和规定，EAS系统的代码模型如图20-50所示。

所有限界上下文都采用了菱形对称架构规定的标准代码模型，只是根据具体情况作了少量调整。各个限界上下文在系统分层架构所处的层次，也通过包的命名空间清晰地呈现出来了。

20.3.4EAS的领域建模

在确定了EAS系统的限界上下文与系统上下文，并通过菱形对称架构和系统分层架构设计出EAS的整体架构后，接下来就进入了战术层面的领域建模阶段。考虑到篇幅原因，我仅选择了业务逻辑相对复杂的培训上下文，运用快速建模法对其进行领域分析建模，获得领域分析模型后，采用庖丁解牛的过程设计聚合，然后相继开展服务驱动设计与测试驱动开发获得最终的领域模型。

1．领域分析建模

领域分析建模阶段的关键是识别领域概念，为限界上下文建立领域分析模型。参考过程模型推荐使用快速建模法进行领域分析建模，它的基础是业务服务规约。以“提名候选人”业务服务为例，它的业务服务规约如下。

 

服务编号：EAS-0202

服务名：提名候选人

服务描述：

　　作为一名协调者

　　我想要提名候选人参加培训

　　以便部门的员工得到技能培训的机会

触发事件：

　　协调者选定候选人后，点击“报名”按钮

基本流程：

1．确定候选人是否已经参加过该课程

2．对培训票提名候选人

3．邮件通知获得提名的候选人

替换流程：

1a．候选人参加过该培训要学习的课程，提示员工已经学习过该课程

2a．提名操作失败，提示失败原因

验收标准：

1．被提名人属于候选名单中的员工

2．提名的票状态必须为Available

3．提名后的票状态为WaitForConfirm

4．候选人获得培训票