遵循系统分层架构与菱形对称架构对代码模型的约束和规定，EAS系统的代码模型如图20-50所示。
所有限界上下文都采用了菱形对称架构规定的标准代码模型，只是根据具体情况作了少量调整。各个限界上下文在系统分层架构所处的层次，也通过包的命名空间清晰地呈现出来了。
20.3.4EAS的领域建模
在确定了EAS系统的限界上下文与系统上下文，并通过菱形对称架构和系统分层架构设计出EAS的整体架构后，接下来就进入了战术层面的领域建模阶段。考虑到篇幅原因，我仅选择了业务逻辑相对复杂的培训上下文，运用快速建模法对其进行领域分析建模，获得领域分析模型后，采用庖丁解牛的过程设计聚合，然后相继开展服务驱动设计与测试驱动开发获得最终的领域模型。
1．领域分析建模
领域分析建模阶段的关键是识别领域概念，为限界上下文建立领域分析模型。参考过程模型推荐使用快速建模法进行领域分析建模，它的基础是业务服务规约。以“提名候选人”业务服务为例，它的业务服务规约如下。
服务编号：EAS-0202
服务名：提名候选人
服务描述：
作为一名协调者
我想要提名候选人参加培训
以便部门的员工得到技能培训的机会
触发事件：
协调者选定候选人后，点击“报名”按钮
基本流程：
1．确定候选人是否已经参加过该课程
2．对培训票提名候选人
3．邮件通知获得提名的候选人
替换流程：
1a．候选人参加过该培训要学习的课程，提示员工已经学习过该课程
2a．提名操作失败，提示失败原因
验收标准：
1．被提名人属于候选名单中的员工
2．提名的票状态必须为Available
3．提名后的票状态为WaitForConfirm
4．候选人获得培训票
