从上面了解到的期望实现的系统功能中看出来，基于各个项目管理中不同业务的特性，我们可以将项目管理这个领域拆分成项目子域、版本子域、任务子域等等。
第三步：对识别出的子领域再次进行细化，从而识别出子领域中的最小单元，从而确定所需要研究的范围边界；
在识别出领域的各个子域之后，我们需要对子域进行进一步的细化，当不能再细化的时候，我们就可以在这个限界上下文中去建立该子领域的领域模型，从而构建出代码模型，完成最终的编程开发。
就像上面列出的步骤一样，我们在对业务领域进行不断的拆分中，会划分出不同的子域。对于业务来说，某些业务很重要，某些可能就无关紧要。因此在划分子领域的过程中，通过子域的重要性和业务功能属性的差异，我们可以将其区分成核心子域、通用子域、以及支撑子域。
核心子域是我们需要解决的业务核心问题，支撑子域是支撑我们的核心子域实现的业务，而通用子域则更多的是每个系统中一些通用的业务功能，例如，认证、授权等等。因此，在实现业务时，我们应该将核心子域的建设摆在首位。
按照上面的步骤，识别出的业务领域如下图所示，因为这里的领域划分，更多的是我个人的想法，所以会存在思考不完善的地方，如果你有别的看法，欢迎指出。
可以看到，这里其实只是识别出了比较粗放的业务子领域，并没有完成对于业务最小单元的边界识别。因为这块的内容会与领域建模关联比较大，所以统一放到下一篇文章中，通过介绍如何用事件风暴的方式完成对于业务领域的建模时一起介绍。
嗯，其实就是完全没想好怎么写。。。
三、个人总结
领域驱动的核心是完成对于领域模型的定义，从而确定业务和应用边界，保证我们的业务模型与代码模型一致性；
领域驱动是一种架构设计的方法论，通过围绕实际业务构建领域模型的方式将复杂的业务领域逐步的拆分，帮最终找出最基础的业务功能与其对应的最基础功能应用的边界；
领域是用来确定功能的范围，范围即是边界，相同的业务问题应该限制在特定的一个功能范围中。一个业务领域可以继续划分，最终实现将业务域进行不断的拆解，从而降低对于整体业务的理解和系统实现的复杂度；
四、参考资料
阿里盒马领域驱动设计实践
DDD理论学习系列——案例及目录
浅谈我对DDD领域驱动设计的理解