20.3.1EAS案例背景

企业应用套件[1]是一款根据软件集团应用信息化的要求开发的企业级应用软件。该软件集团为各行各业提供软件交付服务，以在岸、近岸、离岸等多种模式交付软件。EAS系统提供了大量简单、快捷的操作界面，使得集团相关部门能够更快捷、更方便、更高效地处理日常事务工作，并为管理者提供决策参考、流程简化，建立集团与各部门、员工之间交流的通道，有效地提高工作效率，实现整个集团的信息化管理。

EAS系统为企业搭建了一个数据共享与业务协同平台，实现了人力资源、客户资源和项目资源的整合。系统包括人力资源管理、客户关系管理和项目过程管理等主要模块。系统用户为集团的所有员工，但角色的不同，决定了他们关注点之间的区别。

20.3.2EAS的全局分析

在全局分析阶段，需要针对目标系统进行价值需求分析。

1．价值需求分析

根据参考过程模型的描述，一种有效方法是通过商业模式画布来帮我们确定目标系统的客户、愿景和范围。EAS是一款面向B端的产品，它的客户实际上都是软件集团的员工。员工的角色不同，所属部门不同，职责也不相同，因而对其做客户细分非常有必要。实际上，我们在为EAS进行价值需求分析之前，重点调研了人力资源部、市场部与项目管理部的相关人员。作为支持者（提供部门的业务知识）与受益者（使用EAS的最终用户），他们各自提出了切合自身需要的业务功能，包括：

q市场部对客户和需求的管理，对合同的跟踪；

q项目管理部对项目和项目人员的管理，对项目进度的跟踪；

q人力资源部负责招聘人才，管理员工的日常工作包括工作日志、考勤等。

在对EAS的客户进行细分并确定各自的价值主张时，团队发现遗漏了最重要的利益相关者：集团管理层。作为集团业务的决策者，他们对业务目标的认识有利于更加准确地确定系统愿景。

作为一家提供软件交付服务的集团公司，核心生产力是从事软件开发的人力资源。各个业务部门的主要工作都是围绕着人力资源的供需进行的。决策者的痛点就是无法快速直观地了解公司人力资源的供需情况。例如，客户需要集团提供20名各个层次的Java开发人员，市场部门在确定是否签订该合同之前，需要通过EAS查询集团的人力资源库，了解现有的人力资源是否匹配客户需求。如果匹配，还需要各个参与部门审核人力成本，决定合同标的。如果集团当前的人力资源无法满足客户需求，就需要人力资源部提早启动招聘流程，或从人才储备库中寻找满足需求的候选人。通过EAS，管理人员还能够及时了解开发人员的闲置率，跟踪项目的进展情况，明确开发人员在项目中承担的职责和任务完成质量。

获得商业模式画布的渠道通路比较简单。这是因为EAS与其他创新产品不同，并不需要寻找各种渠道通路对产品进行宣传，只需利用行政力量要求相关部门使用即可。由此推导出来的客户关系，实际上就是对参与EAS系统的各种角色做进一步梳理，了解这些角色在什么时候会使用EAS，又该怎样使用EAS。

EAS是集团的内部系统，不牵涉具体的营收业务，因此它的收益来源更多地体现在对成本的控制和削减上，同时也包含该如何为集团的软件交付业务提供更好的服务与支持。虽然EAS的收益来源并不明显，但对它的思考有利于驱动我们对核心资源和关键业务的发掘。

为了保证EAS的顺利交付，需要哪些核心资源？交付的EAS能够提供哪些关键业务？在确定了EAS的客户、价值主张、收益来源等内容后，参与到商业模式画布头脑风暴的人员能够轻易回答这些问题。由于EAS主要解决人力资源问题，它需要的重要合作也应该与人力资源的招聘、培训有关。最后，EAS是企业内部系统，在考虑实现该系统之前，了解开发该系统需要的成本结构也就显得理所应当。由此，就可以获得图20-4所示的商业模式画布。

[1] 本例的详细需求、设计和代码请在GitHub中搜索“agiledon/eas-ddd”获取。

图20-4EAS的商业模式画布

虽然EAS并非一个创新产品，但在全局分析阶段通过它探索价值需求，会更容易引导客户描绘出心中的设想，并通过这种可视化的形式将其真实地传递出来，形成对问题空间一致理解的，就价值需求达成共识。

一旦确定了商业模式画布的内容，就可以根据商业模式画布各个板块与价值需求之间的关系，获得EAS的价值需求，作为全局分析规格说明书的一部分。组成EAS全局分析规格说明书的价值需求如下所示。

1 利益相关者

q 集团决策者

q 子公司

q 人力资源部

q 市场部

q 项目管理部

q 项目管理办公室

q 财务

q 员工

q 服务中心

2 系统愿景

　　避免信息孤岛，实现人力资源的可控，从而达到人力资源的供需平衡。

3 系统范围

3.1 当前状态

q 创建了由项目经理、业务分析师、开发人员和测试人员构成的特性团队

q 集团项目管理部负责项目的流程管理

q 集团已有OA系统作为部门之间的流程协作与消息通知

q 集团已制订了人才招聘管理办法、项目过程管理办法

q 软件学院和招聘网站的简历作为集团的人才储备库

q 员工培训已有合作的培训公司

q 市场部提供客户和潜在客户名单

q 由集团下达行政命令在集团内部相关职能部门推广EAS系统

3.2 未来状态

q EAS系统在×年×月×日通过用户验收

q EAS系统在×年×月×日上线运行

q 由EAS系统负责客户关系管理、项目管理、人力资源管理

q 通过客户满意度评估EAS系统的价值

3.3 目标列表

q 通过可视化方式体现人力资源的供需状况

q 管理集团与客户和潜在客户之间的关系，管理市场需求，对合同进行跟踪

q 管理项目和项目人员，跟踪项目进度

q 实时调整用人需求，制订招聘和培训计划

q 管理员工考勤、工作日志等日常工作

2．业务需求分析

在完成价值需求分析后，就可以在价值需求的引导与约束下开始业务需求分析。

业务需求分析起始于业务流程，能让目标系统的业务功能“动”起来，执行一系列的活动来满足参与角色的业务价值。为了快速把握EAS的需求全景，可以抓住体现业务愿景核心价值的主流程。既然EAS以“人力资源的供需平衡”为关注核心，那么所有参与角色需要执行的主要业务功能都与该核心价值有关。在价值需求的指引下，可以结合供需平衡将所有参与角色抽象为需求方与供应方，然后站在供需双方的角度思考各个参与角色之间的协作方式与协作过程，如图20-5所示.

图20-5EAS的核心业务流程

图20-5清晰地体现了需求与供应之间的关系，展现了核心业务流程的关键环节。注意，该协作示意图并非项目开始之前的当前状态，而是期望解决供需平衡问题的未来状态。这种协作关系也体现了打破部门之间信息壁垒的系统愿景。根据这一协作示意图，我们可以以泳道图形式的业务流程图表达整个系统的核心流程，如图20-6所示。

这个核心流程体现了业务流程的总体运行过程，属于更为宏观的业务流程表达。许多更为细致的协作细节并没有清晰地表现出来，项目管理流程和招聘流程更是作为子流程被“封装”起来了。为了更为详尽地探索问题空间，这些业务流程也需要进一步得到呈现。从目标系统为参与角色提供服务的角度，我们通过服务蓝图结合业务流程图呈现了EAS的以下业务流程。[1]

q面向市场人员：客户合作的业务流程。

q面向项目管理人员：项目管理流程。

q面向培训专员：培训流程（培训需求是后续提出的需求变更）。

[1] 限于篇幅，本章只提供几个典型的业务流程。

图20-6　核心流程的泳道图

由于EAS的所有用户都是组织内员工，如果使用服务蓝图绘制业务流程，客户角色就是向目标系统发起服务请求的用户，如签订合同业务流程中的市场人员、项目管理流程的项目管理人员和招聘流程的招聘专员。

（1）客户合作

当市场人员向目标系统发起创建市场需求的服务请求时，就形成了从市场需求到合同签订并形成需求订单的客户合作业务流程，它的服务蓝图如图20-7所示。

由于业务规则要求具有独立法人资格的子公司作为市场需求的承担者，因此子公司会成为合同中的乙方。市场人员作为服务蓝图中的客户，并不会参与合同的签订，只是关心子公司的现有资源能否满足市场需求。在签订了合同之后，市场人员可以通过合同信息创建需求订单，并跟踪需求订单，以保持与客户合作的良好关系。子公司作为前台员工需要与市场人员交互，但是市场人员却看不见财务的参与，因为财务核算行为发生在作为前台员工的子公司与财务之间，因此财务属于服务蓝图的后台员工。至于内部支持者，要么是EAS自身，要么就是EAS范围之外的外部系统。

根据客户合作流程的服务蓝图，整个流程由4个业务场景构成：市场需求管理、简历管理、合同管理和需求订单管理。根据业务服务的判断标准，对业务场景的活动进行判断，可以绘制出每个业务场景的业务服务图。

市场需求管理的业务服务图如图20-8所示。

对“查询市场需求”业务服务而言，它虽然没有包含在服务蓝图，但在子公司对市场需求进行评估时，如果不提供这一功能，就无法获得指定的市场需求完成评估。二者提供的服务价值又是完全独立的，有必要为其单独定义一个业务服务。

简历管理的业务服务图如图20-9所示。

客户合作的业务流程说明是由系统生成员工简历，但实际上，这需要子公司的操作人员与系统进行一次交互，目的是导出员工简历，故而识别出该业务服务以满足功能需求。

合同管理的业务服务图如图20-10所示。

合同的签订在线下进行，EAS系统只负责维护合同信息，并将合同扫描版上传到系统中归档，以便市场人员查询合同信息，因此，业务流程中的签订合同活动并未出现在合同管理的业务服务图中。市场人员创建合同的目的其实是归档，以便相关人员（主要是市场人员）查询，故而“归档合同”体现了该业务服务的服务价值。

需求订单管理的业务服务图如图20-11所示。

在梳理客户合作流程的业务服务时，我发现几个领域概念的定义并不清晰：合同、市场需求客户需求和需求订单之间的关系是什么？存在什么样的区别？

当我们发现有多个混乱的领域概念需要澄清时，就要建立统一语言，就这些领域概念达成一致共识。

通过与市场人员的交流，我发现市场部对这些概念的认识也是模糊不清的，甚至在很多场景中交替使用这些概念。在交谈过程中，他们有时还提到“市场需求订单”这个概念。例如在描写市场需求时，他们会提到“录入市场需求”，但同时又会提到“跟踪市场需求订单”和“查询市场需求订单”。在讨论“客户需求”时，他们提到了需要为客户需求指定“承担者”，在讨论“市场需求”时却并未提及这一功能。这似乎是“客户需求”与“市场需求”之间的区别。对于“合同”的理解，他们一致认为这是一个法律概念，等同于作为乙方集团或子公司和作为甲方的客户签订的合作协议，并以合同要件的形式存在。

鉴于这些概念存在诸多歧义，我们和市场人员一起梳理统一语言，一致认为需要引入“订单”（order）的概念。订单不是需求（无论是客户需求还是市场需求）。它借鉴了电商系统中的订单概念，用于描述市场部与客户达成的合作意向。每个合作意向可以包含多个客户需求，相当于订单中的订单项。例如，同一个客户可能提出3条客户需求：

（1）需要5名高级Java程序员、10名中级程序员；

（2）需要8名初级.NET程序员；

（3）需要开发一个OA系统。

这3条客户需求组成了一个订单。一个订单到底包含哪几个客户需求，取决于市场部与客户洽谈合作的业务背景。

引入订单概念后，市场需求与客户需求的区别也就一目了然了。市场需求是市场部售前人员了解到的需求，并未经过评估；公司也不知道能否满足需求，以及该需求是否值得去做。这也是市场需求无须指定“需求承担者”的原因。市场需求在经过各子公司的评估以及财务人员的审核后，就可以得到细化，并在与客户充分沟通后，形成订单。每一条市场需求通过评估，转换为订单中的客户需求。

我们仍然保留了“合同”的概念。“合同”领域概念与真实世界的“合同”法律概念相对应。它与订单存在相关性，但本质上并不相同。例如，一个订单中的每个客户需求可以由不同的子公司来承担，但合同却规定只能有一个甲方和一个乙方。订单没有合同需要的那些法律条款。未签订的合同内容确实有很大部分来自订单的内容，但也只是商务合作内容的一部分而已。在确定了订单后，市场部人员可以跟踪订单的状态，并且在订单状态发生变更时，修改对应的合同状态，但合同的状态与订单的状态并不一致。

在全局分析阶段执行业务需求工作流时，一定要使用统一语言。我们通过业务服务图将业务服务可视化后，对于每一个可能产生歧义的领域概念，一定要大声说出来，及时消除分歧与误解，形成团队内部的统一语言。

（2）项目管理

当项目管理人员（通常为指定该项目的项目经理）开始发起项目立项的服务请求时，就形成了从立项到结项一个完整的项目管理流程，其服务蓝图展现如图20-12所示。

项目管理流程由项目管理人员提交立项申请开始，从管理角度经历了一个项目的完整生命周期。项目管理人员扮演了服务蓝图的客户角色，整个流程的各个阶段都是为项目管理人员服务的。诸如子公司、项目管理部、项目成员和服务中心等只参与项目管理流程，提供交互或支撑行为。

项目管理流程为项目管理人员提供了业务价值。如果要体现目标系统为项目成员提供的业务价值，就需要将项目成员当作服务蓝图的客户，思考它的客户旅程，例如处理迭代问题的流程。可以单独为这个流程绘制服务蓝图。由于视角不同，参与角色的身份也会发生变化。

项目管理流程根据业务目标的不同，分成了4个业务场景：项目管理、项目成员管理、项目计划管理和问题管理。此外，服务中心对硬件资源的分配属于项目管理场景的支持场景，也需要考虑。

在项目管理流程中，同为项目管理目标的业务场景被拆分到首尾两个阶段。在确定项目管理场景的业务服务图时，需要将这两个阶段的业务服务统一，形成图20-13所示的项目管理业务服务图。

服务中心对硬件资源的分配支持了项目立项活动，为整个项目的项目组分配了资源，作为一种支撑活动放在一个单独的业务场景中。其业务服务图如图20-14所示。

分析项目成员管理场景的活动。在添加或移除团队成员时，需要通过OA系统发送通知。通知的发送不在目标系统范围内，也不是由某个参与者发起，而是在添加或移除了团队成员之后进行，属于业务服务的执行步骤，不需要列入图20-15所示的业务服务图。

项目计划管理也分成了两个阶段，合并为一个业务服务图，如图20-16所示。

问题管理业务场景的业务服务图如图20-17所示。

“问题”（issue）概念的获得并非一蹴而就。一开始，我倾向于使用任务（task）来表达这一概念，然而，在需求管理体系中，任务与用户故事（user story）、史诗故事（epic）、缺陷（defect）属于同一等级的概念，我需要寻找到一个抽象概念来同时涵盖这几个概念，由此就得到了“问题”概念。在Jira和GitHub的需求管理工具中，都使用了这一领域概念。

项目管理者在创建问题时，会指定问题的基本属性，如问题的标题、描述、问题类型等。那么，问题所属的迭代、承担人（owner）、报告人（reporter）是否也属于问题的属性呢？在确定问题管理业务场景的业务服务图时，我确实困惑不已。例如“分配问题给迭代”与“分配问题给项目成员”都可以认为是在编辑问题的属性。既然业务服务为角色提供了服务价值，很明显，无论是将一个创建好的问题分配给迭代，还是将其分配给项目成员使其成为问题的承担人，都具有项目管理价值，是由项目管理者向目标系统发起的一次独立而完整的功能交互，应该分别识别为两个业务服务。

在确定项目管理的业务服务时，统一语言再一次发挥了价值。最初在确定项目管理的业务流程时，项目管理者要查看问题的完成情况以了解迭代进度，故而将该流程中的一个活动命名为“查看问题完成情况”。在识别业务服务时，我认为该名称没有清晰地体现该业务服务的服务价值，经过与业务分析人员沟通，认为该业务服务需要清晰地表达问题在迭代周期内的过程，准确的术语是“进度”（progress），将其命名为“跟踪问题进度”（trackingissue progress）更加符合该领域的统一语言。

（3）培训

培训的目的是提高员工的技能水平，需要根据员工的职业规划与企业发展制订培训计划，开展培训。培训的整个管理由人力资源部的培训专员负责。培训流程除了牵涉到培训专员，还牵涉到部门协调者、员工主管和员工本人。系统将分配给员工的培训机会称为票（ticket），这实际上是领域概念的一种隐喻。培训专员发起培训的过程，实际上就是分配票的过程，整个流程如图20-18所示。

培训专员在分配票之前，会设定过滤器。过滤器主要用于过滤员工名单，获得一个与该培训相匹配的提名候选名单（candidate）。培训专员将票分配给部门协调者，部门协调者再将票分配给属于提名候选名单中的部门员工。员工在收到培训邮件后，可以选择“确认”或“拒绝”，若员工拒绝，票会退回给部门协调者，由部门协调者进行再分配，最终会形成一个提名名单（nomination）。

培训期间，每个参与培训的员工都需要通过培训专员出示的二维码签到，包括培训开始签到和培训结束签到。培训结束后，培训专员可以获得出勤名单。比较出勤与提名名单，可以获得缺席名单。培训专员确认了缺席名单后，系统会根据黑名单规则将缺席人员加入黑名单。员工若被列入黑名单中，将来就不会再出现在提名候选名单中，除非又被移出了黑名单。培训流程如图20-19所示。

图20-19　培训的服务蓝图

培训专员在确定培训计划并分配票时，还可以事先设置有效日期，用于判断票的有效期限。从发起培训开始，到培训结束，一共有4个重要的截止时间（deadline）：

q提名截止时间；

q缺席截止时间；

q培训开始前；

q培训结束前。

在不同的截止时间，员工取消票的流程都不一样，票的处理规则也不相同，如图20-20所示。

在提名截止时间之前，获提名的员工可以取消票。取消后，系统会分别发送邮件给部门协调者与员工主管，只要任意一人批准了该取消请求，就认为取消成功，该票又会恢复到可用状态。在缺席截止时间之前，员工可以取消票。取消后，系统会发送邮件通知部门协调者和员工主管，但无须他们审批，而是直接由培训专员负责处理该票。处理票时，会先检查分配该票时设置的活动（action）策略，要么由系统自动处理，要么由培训专员处理该票。处理票有3种活动策略：

q将票分享给别的协调者；

q将票分配给员工；

q让票作废。

在培训开始前，不允许员工再显式地取消票。如果员工在收到票后一直未确认，系统会检查分配该票时设置的策略，要么由系统自动处理，要么由培训专员处理该票，处理票的策略与前相同。一旦培训开始后，就不再允许员工取消票，如果有事未能出席，应提交请假申请。

部门协调者在将票分配给员工后，也可以取消已经分配出去的票。不同截止日期的取消流程不同，如图20-21所示。

部门协调者取消票的流程与员工取消票的流程比较相似，不同之处在于取消票时无须审批，直接就可处理。在提名截止时间之间，处理票的活动策略有3种：

q备选名单先到先得；

q备选名单按优先级；

q手动从备选名单中选择。

这里的提名备选名单（backup）就是从之前设置的过滤器生成的提名候选名单中剔除掉已经被提名的员工列表后的名单。

培训专员也可以取消票，其流程如图20-22所示。

该执行流程与部门协调者取消票的流程几乎完全相同，这里不再赘述。

在分析培训流程时，我分别运用了服务蓝图和业务流程图展现了分配票、培训和取消票的业务流程，并根据不同阶段的业务目标确定了业务场景。

票的分配业务服务图如图20-23所示。

在明确票的分配业务场景下的业务服务时，我们发现关于“票的分配”存在两个不同的业务服务：

q分配票给部门协调者；

q分配票给部门员工。

票的分配目标不同，而行为都是分配，是否存在语义不清的问题？实际上，虽然都是对票的分配操作，但它们的业务含义与服务价值完全不同。获得票的部门协调者并非票的拥有者，不会参加培训，而是拥有了分配票的资格，可以将票进一步分配给员工。为避免混淆这两个概念，可以将分配票给部门员工的操作视为对员工的提名。这就明确了如下概念。

q分配票给部门协调者：获得票的员工为部门协调者，并非参加培训的员工。

q提名部门员工：将票分给部门员工，使得他（她）具备了参加培训的资格。

虽然都是部门员工，但是在分配票和培训的不同业务场景中具有不同的身份。明确这些身份（角色），可以更加准确地体现部门员工与培训的不同关系。

q候选人：利用过滤器筛选或直接添加的员工，都是培训的候选人。这些候选人具备被培训专员或协调者提名参加培训的资格，但并不意味着候选人已经被提名了。

q 被提名人：指获得培训票要求参加培训的员工，即被提名的对象。

q备选人：指备选名单中的员工，备选名单是提名候选名单中剔除掉被提名人的员工列表。

q学员：被提名人在收到培训票后确认参加，就会成为该培训的学员。

无论是明确“分配”的含义，还是进一步细化部门员工的不同身份，都是在定义和提炼统一语言。这些统一语言的确定需要即刻反映在业务服务图中。

票的取消业务服务图如图20-24所示。

不同参与者的取消流程虽然不同，但在业务服务图中，实际要执行的业务服务都是“取消票”。培训专员和系统都可以处理票，区别在于一个是人工，一个是自动，后者的触发条件与触发时机相对比较复杂。对这些领域逻辑的描述可以在领域建模阶段通过业务服务规约进一步细化。

获得提名并参加培训的部门员工称为“学员”，如此可以更好地体现其身份。培训的业务服务图如图20-25所示。

培训业务规则规定，如果学员没有提交培训请假申请或请假申请未通过，却未曾参加培训且未签到，会被视为缺勤。在培训流程的服务蓝图中，根据业务规则，缺勤学员会被放入黑名单，然而这一活动并未在业务服务图中体现出来。这是因为学员被加入黑名单实际是“确认缺勤名单”业务服务产生的一个结果，并非一个独立的业务服务。

分析EAS的业务需求时，从业务流程到业务场景，再从业务场景到业务服务，应该是一个水到渠成的过程。在这个过程中，最好能引入“现场客户”（极限编程中的一个实践），共同探索业务需求，梳理出问题空间的业务需求全貌。

为了避免分析瘫痪，在全局分析阶段，业务需求分析在获得业务服务这个粒度时就可以结束，进入架构映射阶段。然而，对业务服务做进一步细化仍然属于需求分析的过程，与开发团队开展架构映射属于两个并行不悖的工作，细化获得的业务服务规约也将作为领域建模阶段的重要输入。因此，需求分析人员也可在全局分析阶段针对核心子领域的业务服务编写业务服务规约。

组成EAS全局分析规格说明书的业务需求如下所示。

1 业务流程

包括EAS的核心流程与各个具体的业务流程，可通过业务流程图或服务蓝图呈现。前文已述，现略去。

2 业务场景和业务服务

针对每个具体的业务流程，按照业务目标进行划分，获得每个具体的业务场景，并按照业务服务的判断标准识别业务服务，通过业务服务图呈现出来。前文已述，现略去。

3 业务服务规约

对每个业务服务进行细化，获得业务服务规约。

3.1 客户合作

3.1.1 市场需求管理

（1）创建市场需求

服务编号：EAS-0001

服务描述：

　　作为市场人员

　　我想要创建一条市场需求

　　以便随时了解市场需求的状态

触发事件：

　　市场人员输入市场需求，点击“创建”按钮

基本流程：

1．验证输入的市场需求，包括需求名称、描述、客户、备注

2．按照规则生成市场需求编号

3．验证市场需求名称是否已经存在

4．创建市场需求

替代流程：

1a．当市场需求名称在系统中已存在，给出提示信息

4a．若市场需求创建失败，给出失败原因

验收标准：

1．市场需求的名称只能为中文、英文或数字，长度不超过50个字符，不能重复

　　　2．输入的市场需求中，必须包含市场需求名称、描述和客户，客户为系统已有客户，备注为可选

3．市场需求编号规则为：EAS-客户ID-自增长数，市场需求编号不允许重复

4．市场需求被成功创建

3.1.2 合同管理

（1）归档合同

服务编号：EAS-0011

服务描述：

作为市场人员

我想要对合同进行归档

以便保存合同副本，避免合作纠纷

触发事件：

市场人员选择合同文档，点击“上传”按钮

基本流程：

1．验证文档类型的有效性

2．上传合同文档

3．保存合同文档

4．更新合同信息

替代流程：

1a．若上传的文档类型并非PDF文档，给出提示信息

2a．若上传的文档超出系统规定的文件大小，给出提示信息

3b．若上传合同文档时，文件传输失败，给出失败原因

4a．更新合同信息失败，给出失败原因

验收标准：

1．归档的合同文档只能为PDF文件，可仅验证文档文件的扩展名

　2．服务器归档主文件夹为contract/archive，归档保存时，需验证该文件夹是否存在，如果不存在，需要创建该文件夹

3．为合同归档文件创建子文件夹，子文件夹名为合同ID

4．若归档时，在指定文件夹中已有同名文件存在，则为“另存为”操作，当前文件名增加“（1）”作为后缀

5．合同的归档文件属性添加归档文件夹路径

……

3.3 项目管理

……

3.3.3 项目成员管理

（1）添加项目成员

服务编号：EAS-0105

服务描述：

作为项目管理者

我想要添加项目成员

以便管理项目成员

触发事件：

项目管理者选定员工和项目角色，点击“添加”按钮

基本流程：

1．验证员工是否工作在其他项目

2．将员工加入项目团队，成为项目成员

3．修改员工的工作状态

4．发送邮件通知员工

5．为员工简历追加项目经验

替代流程：

1a．选定员工如果已经加入其他项目，给出提示

2a．添加员工失败，给出错误信息

5a．若员工已具备该项目经验，则忽略

验收标准：

1．选定的员工应为“on bench”状态

2．员工被加入项目团队后，状态应变更为“项目中”

3．员工简历中的项目经验信息不能重复

4．员工简历中的项目经验包括：项目名称、项目描述、担任的项目角色

3．划分子领域

全局分析阶段对问题空间的识别也是对客户痛点与系统价值的识别。之所以要开发目标系统，就是要解决客户的痛点，并为客户提供具有业务价值的功能。在识别痛点与价值的过程中，需要始终从业务期望与愿景出发，与不同的利益相关者进行交流，如此才能达成对问题空间的共同理解。

对EAS而言，集团决策层要解决“供需平衡”这一根本的痛点，就需要及时了解当前有哪些客户需求、目前又有哪些人力资源可用，这就需要打破市场部、人力资源部和项目管理部之间的信息壁垒，对市场需求、人力资源、项目的信息进行统计，提供直观的分析结果，进而根据这些分析结果为管理决策提供支持。我们需要就这几个主要部门了解部门员工的痛点和对价值的诉求。

市场部员工（市场人员）面临的痛点是无法通过人工管理的方式高效维护与客户的良好合作关系，故而其价值诉求就是提高客户关系管理的效率，使得能够快速地响应客户需求，敏锐地发现潜在客户，掌握客户动态，进而针对潜在客户开展针对性的市场活动。市场部员工希望能够建立快速通道，及时明确项目承担者（即子公司）是否能够满足客户需求，降低市场成本。市场部门还需要准确把握需求的进展情况，跟进合同签署流程，提高客户满意度。

人力资源部员工（招聘专员）的痛点是需要制订合理的招聘计划，使得聘用的人才满足日益增长的客户需求，又不至于产生大量的人力资源闲置，导致集团的人力成本浪费。站在精细管理的角度考虑，从潜在的市场需求开始，招聘专员就需要与市场部、子公司共同确定招聘计划。制订计划的依据在于潜在的人力资源需求，包括对技能水平的要求、语言能力的要求，同时也需要考虑目前子公司的员工利用率，并参考历史的供需关系来做出尽可能准确的预测。员工的技能是一种重要的输出资源，人力资源部需要针对客户对人员能力的要求制订培训计划，在企业内部组织员工培训，提升员工技能，如此就能以最小成本输出最大的人力资源价值。因此，人力资源部的价值诉求就是让招聘与培训具有计划前瞻性与精确性，更好地在客户需求与人力资源之间维护供需的平衡。

项目管理部负责企业的“生产管理”，对项目以及项目成员的管理直接关系到客户满意度。在没有EAS之前，市场部的苦恼是不了解已签合同的项目执行情况，即使市场部主动与项目管理部进行沟通，项目管理部也无法提供精确的项目信息，更谈不上及时了解项目的进度情况。因此，市场部的价值诉求是了解项目进度以促进与客户的良好合作关系，而项目管理部的价值诉求是及时了解项目过程执行情况，发现不健康的项目，通过项目管理手段规避延迟交付甚至交付失败的风险，提高项目的成功率。

识别了痛点与价值，即可借此划分子领域细分问题空间。并通过识别核心子领域、通用子领域和支撑子领域来区分核心问题和次要问题。

由于EAS是为软件集团应用信息化服务的，我们可以在识别出痛点与价值的基础之上，从业务职能与业务概念相结合的功能分类策略确定整个问题空间的子领域，由此获得的核心子领域如下：

q决策分析；

q市场需求管理；

q客户关系管理；

q员工管理；

q人才招聘；

q技能培训；

q项目进度管理。

除了这些核心子领域，诸如组织结构、认证和授权都属于通用的子领域，每个核心子领域都需要调用这些子领域提供的功能。注意，虽然通用子领域提供的功能不是系统业务的核心，但缺少这些功能，业务却无法流转。之所以没有将这些功能识别为核心子领域，是因为有对问题空间的理解分析。例如，组织结构管理是保证业务流程运转以及员工管理的关键，用户的认证与授权则是为了保证系统的访问安全，都没有直接对“供需平衡”这一业务愿景提供业务价值，因而不是利益相关人亟待解决的痛点。

在分辨系统的利益相关者时，服务中心作为参与EAS的业务部门，主要为项目及项目人员提供工位和硬件资源，要解决的是资源分配的问题。这一功能的引入固然可以帮助企业降低运营成本，却与价值需求中的系统愿景没有直接关系，因此可以将该子领域作为一种支撑子领域。除此之外，消息通知和文件上传下载也支持了大部分核心领域的执行活动，都属于独立的支撑子领域。

EAS的子领域映射图如图20-26所示。

划分子领域分解了问题空间，使得团队能对EAS达成共同理解，识别出来的各个子领域也将作为解空间形成的架构方案的参考，尤其是系统分层架构的参考。子领域也属于全局分析规格说明书的一部分。

本文摘录《解构领域驱动设计》。需要获取完整电子版可以关注小编，后台私信：“333”获取。

本书全面阐释了领域驱动设计（domain-driven design，DDD）的知识体系，内容覆盖领域驱动设计的主要模式与主流方法，并在此基础上提出“领域驱动设计统一过程”（domain-driven design unified process，DDDUP），将整个软件构建过程划分为全局分析、架构映射和领域建模3个阶段。除给出诸多案例来阐释领域驱动设计统一过程中的方法与模式之外，本书还通过一个真实而完整的案例全面展现了如何进行领域驱动设计统一过程的实施和落地。为了更好地运用领域驱动设计统一过程，本书还开创性地引入了业务服务、菱形对称架构、领域驱动架构、服务驱动设计等方法与模式，总结了领域驱动设计能力评估模型与参考过程模型。本书提出的一整套方法体系已在多个项目中推广和落地。

本书适合希望领会软件架构本质、提高软件架构能力的软件架构师，希望提高领域建模能力、打磨软件设计能力的开发人员，希望掌握业务分析与建模方法的业务分析人员，希望学习领域驱动设计并将其运用到项目中的软件行业从业人员阅读参考。