这是我们DDD workshop的作业，仅供练习。
案例1. 一家咨询服务公司的Timesheet系统
需求
1) 公司的所有员工能够登陆到系统填写每周工作的时间、内容。
2）公司有两部分员工，一类是办公室人员，一类是咨询人员；
3）咨询人员是为某个项目工作，在每个项目里的角色不尽相同；每个项目的Timesheet要求也不同，根据角色的不同有不同的定义，比如开发人员要求填写工作的story号等。每个项目的PM可以批准项目成员填写的Timesheet内容。
4）办公室人员的工作是与办公室的事情相关，有很多的工作项目，每个办公室要求的内容不同。每个办公室经理可以批准办公室人员填写的Timesheet内容。
问题空间与子域
问题空间
一家咨询服务公司的Timesheet系统。
子域：
领域：这个公司的Timesheet
子域：这家公司的Timesheet业务及为其服务的一系列活动。
其业务活动分析如下：
PM定义项目Timesheet填写模版，项目成员登陆系统，选定项目，展示模版，填写内容。PM批准其填写的Timesheet。
办公室管理人员定义办公室Timesheet填写模版，办公室人员登陆系统，选定工作项目，展示模版，填写内容。
- Timesheet子域 - 核心子域
- 项目模版资源 - 支撑子域
- 办公室模版子域- 支撑子域
- 项目及人员信息子域- 支撑子域
- 办公室及人员信息子域- 支撑子域
- 用户登陆身份子域- 通用子域
解决方案与限界上下文
限界上下文是解空间的内容，要求限界上下文中的术语是通用的无歧义的。在Project Template域中存在项目经理，而在Timesheet中则没有项目经理这个概念，只有timesheet批准人这么一个术语。
{:height=”300px” width=”400px”}
限界上下文映射
{:height=”300px” width=”400px”}
通用术语
{:height=”300px” width=”400px”}
如何划分上下文
这里面最重要的依然是两个概念，子域与限界上下文。如何定义和划分限界上下文是一个需要根据当前需求和客户一起讨论确定的。
限界上下文的不同决定了解空间的不同，限界上下文不易过早缩小，否则会带来很多小系统或者小模块，使得集成方式变得过于复杂。限界上下文过大，有可能会导致大而全的解空间，使得问题过于复杂，领域混乱。那么如果限界上下文中的术语没有歧义，是否就可以选择大而为之呢？
这一题感觉可以将Project TemplateContext 与 Timesheet Context合并，减少复杂性。