Project Context

项目上下文

业务需求

项目上下文的业务需求主要包括：项目管理、项目成员管理、迭代与问题管理等功能。

管理员可以创建项目，指定项目类型并配置项目的基本信息。项目项目，项目管理人员可以为其添加项目成员，并制定项目成员的角色。当一名员工成为了该项目的成员后，参与该项目的经验就可以作为简历的一部分。项目管理人员可以创建一个或多个迭代，并为每个迭代确定一个迭代目标。如果没有创建迭代，系统会为项目创建一个默认的待办项（Backlog）迭代。创建迭代时，需要指定迭代的周期即开始时间和截止时间。迭代需要手动选择开始才会生效，迭代开始时，需要根据当前日期显示剩余天数；如果当前时间到达截止日期，迭代也不会自动关闭，只会提示“剩余0天”，项目管理人员可以手动地关闭迭代，并将当前迭代未完成的问题移到下一个已经开始或还未开始的迭代。如果没有符合条件的迭代，则这些问题会被移到待办项迭代中。

一个问题（Issue）可以是软件的缺陷，一个项目的具体任务，一个业务功能需求或者是一个需要解决的技术难题等。创建问题时，需要指定问题所属的项目、问题类型、问题概要和报告人，设置问题的优先级以及问题的经办人。如果未指定经办人，则系统会自动将创建问题的用户设置为经办人。当然，还需要输入问题的描述，并设置该问题的标签。关注该问题的用户可以为问题添加评论，或者上传附件。在创建问题时，还可以指定问题所属的迭代，指定的迭代只能是当前正在进行或未来要进行的迭代。

每个问题有一个状态，用来表明问题所处的阶段。这些状态包括：

• Open ：表示问题被提交，等待团队成员处理。
• In Progress ：问题在处理中，尚未完成。
• Resolved ：问题已解决，但解决结论需要确认。
• Reopened ：已解决的问题未获认可。
• Closed ：已解决的问题得到认可和确认，置于关闭状态。

默认情况下，问题的状态为Open。如果该问题已经分配给项目成员并开始解决该问题时，项目成员需要将问题状态修改为In Progress。一旦解决了该问题，就应标记该问题为Resolved。只有问题的报告人才可以修改问题的状态为Reopened或Closed。任何状态的变更都会发送邮件通知报告人。由于每个问题都可以创建多个子任务，当问题正在处理中时，如果此时有部分子任务还未标记为Resolved，需要提示用户部分子任务还未解决，一旦用户确认问题已经解决并被标记为Resolved状态，该问题下的所有子任务状态也必须标记为Resolved。如果问题划分了子任务，则关注该问题的用户也可以为子任务添加评论。

在创建或编辑问题时，团队成员可以对问题进行评估，给出问题的故事点（Story Point）。在对迭代和项目进行汇总统计时，可以根据问题或故事点进行汇总统计。

问题被创建后，团队成员可以编辑问题，例如修改标题、描述、估算、重新分配报告人和经办人等。每次对问题的修改都需要记录下来，作为当前问题的变更记录（ChangeHistory）。如果修改了报告人，需要向之前的报告人和目前负责的报告人发送邮件通知；如果修改了经办人，需要向报告人以及之前的经办人、目前负责的经办人发送邮件通知。当一个问题分配给团队成员时，团队成员可以在该问题下填写项目日志。

领域分析模型

分析项目上下文的需求，可以通过名词动词法初步获得项目上下文的主要领域概念，包括：

• 项目（Project）
• 项目成员（TeamMember）
• 迭代（Iteration）
• 问题（Issue）
• 子任务（SubTask）
• 评论（Comment）
• 附件（Attachment）
• 变更记录（ChangeHistory）

领域分析模型如下：

领域分析模型除了包含主要的领域概念之外，还将一些主要的属性定义为领域类，同时确定了它们之间的关系。由于一个问题只能指定一个报告人和一个经手人，因此Issue与TeamMember之间的关系是一对二的关系。

领域设计模型

领域设计模型如下图所示：

聚合根实体分别为：Project、Iteration、Issue、TeamMember、Comment、Attachment与ChangeHistory。图中仍然用面向对象的合成或聚合表现聚合根之间的关系，但在设计时，上游聚合根应通过ID与下游聚合根建立关联关系。比较特殊的是Issue聚合根，它需要提供IssueId与SubTaskId和下游聚合Comment建立关联。

场景驱动设计

针对用例可以确定业务场景，并利用场景驱动设计细化领域设计模型。例如“分配问题给项目成员”领域场景，可以分解任务为：

• 分配问题给项目成员
  • 获得问题
  • 分配问题给经办人
  • 更新问题
  • 创建问题的变更记录
  • 通知报告人
    • 生成报告人通知
    • 发送通知
  • 通知经办人
    • 获取经办人信息
    • 生成经办人通知
    • 发送通知

根据角色构造型进行职责分配获得时序图如下所示：

这一领域场景看似简单，但它实际上牵涉到项目上下文多个领域对象，以及与OA集成上下文、员工上下文之间的协作。其中，EmployeeClient与NotificationClient是面向这两个上游上下文定义的南向网关。