前言
断断续续的也有在闲余时间接触领域驱动设计的相关知识，因为目前在工作中更多的还只是一名 crud boy，因此目前也只是对其中的某些知识点有知晓，实际使用的比较少，仅此而已。因此，趁着这个春节假期，整理了一下自己的 github 帐号，同时结合自己定的学习计划以及自己的期望发展方向，决定从一个真实的案例来梳理领域驱动的相关知识。
本篇文章是开篇，因为领域驱动设计相关的知识真的不怎么好懂，如果行文中出现错误的地方，欢迎大家在评论区指出，先行感谢。
当然，talk is cheap, show me the code，作为一名 .NET 开发人员，实例中的服务端代码全部是基于 ASP.NET Core 框架进行搭建的。
系列目录
Step by Step
不清楚大家在接触领域驱动的相关知识时，是不是一上来就是领域驱动经典的四层架构，然后什么是实体、值对象、聚合，它们之间有什么异同以及与传统的开发模式又是什么，领域模型又是什么东东，最终接触到一大堆的概念，结合上网搜到的示例项目代码，结果最后就知道了几个名词。
当然，这些都是领域驱动设计中比较重要的知识点，可能是自己入行较短，按照上面的这个顺序看了一遍，看完之后，嗯，貌似最后都没看完，我只能是下面的这种表情。。。因此，为了不让像我这样的小白用户一上来就用药过猛，所以这里我换一种方式来尝试解释我所认为的领域驱动设计，如若存在偏差，希望可以帮忙指出。
第一篇介绍的是我认为领域驱动设计中一个最基础的东西，也是很多文章中并没有说的，如何去识别出业务领域并进行划分。
案例分析
因为在识别领域时，需要做到对于业务流程有比较深刻的了解，至少应该做到有相关软件的使用经历，因此在这个系列的文章中，我选择的是项目管理软件作为文章的示例项目。最终实现的各种需求是基于禅道项目管理软件这个开源项目的，因此，在开发这个项目之前，我们可以先看看禅道这个项目管理系统中所包含的功能模块。毕竟，只有在了解需求之后才好进行下一步的工作。
在这个开源的项目管理系统中，主要包含了如下的几个功能。
除了一些基础的权限相关功能，站在项目产品的角度，禅道包含了对于产品的分支、团队成员、迭代版本、功能模块、功能需求等数据信息的维护，同时针对项目可以去设定各种任务、以及可以提 bug 等等任务操作。
当然，系统所包含的功能还可以继续往下展，如果按照我们面向数据库开发的经验，在弄清楚系统的各项功能后，可能就是去建各种的表了，继而识别出各个表之间的关联关系，然后就 ctrl c、ctrl v 的开干了。当然，这里既然选择采用一种新的方式进行开发，忘掉我们原来的经验，从一个新的角度开始。
领域划分
领域驱动设计，在维基百科中对于领域的解释如下，因为词条的中文解释应该是机翻的，所以这里放出英文原文，下方的中文是我基于个人理解所提供的翻译，仅供参考。
A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software;
领域是一种关于知识、影响或是活动的范围限定。软件的领域是用户想要通过使用该程序所要达到的主体功能。
范围，即是边界，能够置于相同范围内的事物必定是具有着某种相同的特性，我们通过代码的手段来解决现实中的问题时，也会将某些共通的业务放到一块。
因此，在使用领域驱动的思想来指导软件开发的过程中，我们需要按照一定的业务规则将期望达成的业务进行细分，在最终划分出的一个个小业务范围内，通过建立领域模型的方式，指导代码实现，从而解决具有共同特性的问题，因此，领域驱动设计中的领域就是这个业务边界范围内想要解决的业务问题域。
接下来，针对我们期望实现的项目管理系统，就是需要按照一定的业务规则，完成我们的业务领域的划分。
第一步：确定研究对象，明确我们将要研究的业务领域，识别出最终需要解决的业务问题；
我们最终想要实现的目标是一个项目管理系统，因此这里我们的研究对象就是项目管理。
第二步：对研究对象按照一定的业务逻辑进行细分，将领域进一步的划分成多个子领域；
从上面了解到的期望实现的系统功能中看出来，基于各个项目管理中不同业务的特性，我们可以将项目管理这个领域拆分成项目子域、版本子域、任务子域等等。
第三步：对识别出的子领域再次进行细化，从而识别出子领域中的最小单元，从而确定所需要研究的范围边界；
在识别出领域的各个子域之后，我们需要对子域进行进一步的细化，当不能再细化的时候，我们就可以在这个限界上下文中去建立该子领域的领域模型，从而构建出代码模型，完成最终的编程开发。
就像上面列出的步骤一样，我们在对业务领域进行不断的拆分中，会划分出不同的子域。对于业务来说，某些业务很重要，某些可能就无关紧要。因此在划分子领域的过程中，通过子域的重要性和业务功能属性的差异，我们可以将其区分成核心子域、通用子域、以及支撑子域。
核心子域是我们需要解决的业务核心问题，支撑子域是支撑我们的核心子域实现的业务，而通用子域则更多的是每个系统中一些通用的业务功能，例如，认证、授权等等。因此，在实现业务时，我们应该将核心子域的建设摆在首位。
按照上面的步骤，识别出的业务领域如下图所示，因为这里的领域划分，更多的是我个人的想法，所以会存在思考不完善的地方，如果你有别的看法，欢迎指出。
可以看到，这里其实只是识别出了比较粗放的业务子领域，并没有完成对于业务最小单元的边界识别。因为这块的内容会与领域建模关联比较大，所以统一放到下一篇文章中，通过介绍如何用事件风暴的方式完成对于业务领域的建模时一起介绍。
嗯，其实就是完全没想好怎么写。。。
个人总结
- 领域驱动的核心是完成对于领域模型的定义，从而确定业务和应用边界，保证我们的业务模型与代码模型一致性；
- 领域驱动是一种架构设计的方法论，通过围绕实际业务构建领域模型的方式将复杂的业务领域逐步的拆分，帮最终找出最基础的业务功能与其对应的最基础功能应用的边界；
- 领域是用来确定功能的范围，范围即是边界，相同的业务问题应该限制在特定的一个功能范围中。一个业务领域可以继续划分，最终实现将业务域进行不断的拆解，从而降低对于整体业务的理解和系统实现的复杂度；
