领域驱动设计-- 模型

什么是模型

从领域驱动的战略设计进入战术设计，简单说来，就是跨过系统视角的限界上下文边界进入它的内部，从分层架构的逻辑分层进入到每一层的内部。在思考内部的设计细节时，首先需要思考的问题就是：什么是模型（Model）？

模型是从哪里来的，怎么得出来的。注：这里的模型不仅仅是我们数据库建模

还是来看看 Eric Evans 对模型的阐述：

为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系。所需知识的广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。

模型的生成

针对现实世界的问题域建立抽象的模型形成解决方案，这个过程视软件复杂度而定，可能会非常漫长。这其间需要迭代的分析、设计和实现，逐步浮现出最终可行的方案，构建满足需求的软件。从问题域到解决方案域，或许有多种途径或手段（取决于你的问题域的复杂度），然而针对复杂问题域，通过建立抽象的模型来映射现实世界的多样性，就好似通过数学公式来求解一般，是实践证明可行的道路：

首先什么是问题域
在软件工程中，问题域是指被开发系统的应用领域，即在客观世界中由该系统处理的业务范围。

建模视角：

如果我们是以数据为核心，关注数据实体的样式和它们之间的关系，由此建立的模型就是“数据模型”。
如果我们需要为系统外部的客户端提供服务，关注的是客户端发起的请求以及服务返回的响应，由此建立的模型就是“服务模型”。
而领域驱动设计则强调以领域为中心，通过识别领域对象来表达业务系统的领域知识包括业务流程、业务规则和约束关系，由此建立的模型就是“领域模型”。这三种不同的模型，就是不同视角的模型驱动设计获得的结果。因此，整个模型驱动设计可以分为两个不同的维度来表现模型，即建模视角与建模活动。

为什么需要领域建模：
我们绝大数的软件开发采用的是 数据库建模(数据模型) – 本质上是数据视角 关注的数据和数据的关系
这种关系会体现在表与表的关系上

这种设计的问题
业务初期，我们的功能大都非常简单，普通的CRUD就能满足，此时系统是清晰的。随着迭代的不断演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。模块彼此关联，谁都很难说清模块的具体功能意图是啥。修改一个功能时，往往光回溯该功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。
我相信绝大多数同学都会遇到过这个问题，在刚开始开发的时候，我们是这么设计的，随着我们的业务不断发展，我们的项目不断扩大，同时我们的表也是一个订单大表，包含了非常多字段。在我们维护代码时，牵一发而动全身，很可能只是想改下商品的功能，却影响到了创单核心路径。虽然我们可以通过测试保证功能完备性，但当我们在订单领域有大量需求同时并行开发时，改动重叠、恶性循环、疲于奔命修改各种问题。

当然我们如果是一个简单而且不会有太多变化的系统完全可以采用这种方式 – 因为简单。

建模过程

1. 首先我们数据建模的方式：我们直接从需求或者系统定义中提取出我们需要的数据 – 分析哪些数据是中间状态，哪些数据需要做持久化，根据持久化的数据和数据之间关系采用uml来进行数据实体之间的建模
2. 上面是我们常用的建模方式：得到的东西是一种uml图：关系图，时序图等，我们的思路主要是聚焦到数据上，忽略了数据产生时所处的环境（我们领域模型所说的界限上下文）
3. 脱离了上下文产生的问题：首先在最初的建模时候，我们的数据是有考虑过我们产生的上下文，比如我们会给数据增加状态等，但是随着迭代，我们数据的增加和修改是不会在去回归我们上下文，变的随意，这也是导致我上面所说的表越来越大。
4. 那领域建模是怎么去建模的：首先不管是什么建模方式都会去关注数据，那我们领域建模的核心关注点是在于我们领域的划分和界限上下文的划分
5. 那怎么划分领域和界限上下文呢？后面会有专门的介绍，在领域建模中我们也必然会有数据库相关的模型也是会用到我们的uml等，但是我们核心的确是我们怎么划分我们的领域和上下文，将他们以可见和易懂的方式保存下来，然后体现到我们的实现中。