java领域模型设计实例_产品设计-产品经理角度看待领域模型

“领域驱动设计”中的“领域”一词指的是要实现的软件系统所要解决的实际问题所处的整个领域范围，它不仅包括系统架构的相关问题，还涉及到系统所支持的业务等内容，但它是与具体的开发技术无关的。也就是说 DDD 关注的是要构建的系统中，关于所要解决的问题的业务、流程和数据等内容是如何工作的，在这些东西理清之后，DDD 去构建出一个模型，接着再去选择具体的实现技术。DDD 强调的是解耦具体实现技术，所以它可以迅速梳理核心业务逻辑。DDD的思想方法主要被开发人员采用，但是作为产品经理，在对其了解及实际应用的过程中，发现了DDD在需求分析、方案设计上也有极大的作用。

1、产品经理与开发人员讨论场景

统一模型，这点笔者是有所感触的。在某公司实习期间，和PM的交流中会出现。

产品经理：“在已有的基础之上增加X这个功能因该很简单，能很快完成吧？”
开发人员: “代码不是这么实现的，所以新增这个功能的工作量很大。”
产品经理：“那你们是怎么实现的？”
开发人员：“balabala~。”

然后，这个需求根据其重要和紧急程度性，要么经过较长的开发时间开发完成，要么就被推迟或者砍掉。如果多方参与到领域模型的设计，并在各自的工作中使用同一个模型。由此，增加双方的交流，提高沟通和工作效率。

2、建模人员参与程序开发

领域驱动设计只是一种设计模式，要建设一个持续有活力的、能轻松应对复杂多变业务的系统，需要架构师、程序员、产品经理和领域专家以及其他团队成员共同努力。领域模型不会一成不变，不断的变化和重构才能让领域模型更精炼和有活力。另外，

建模人员都必须花时间了解代码。每一个开发人员都必须学会用代码来表达模型，并且不同程度地参与模型讨论，与领域专家保持联系。才能保障领域模型的落地。

我们一直在路上。以建模为例，模型很多时候是我们在设计构想一件事物时做的高度抽象，它是事物的骨架，也是实施的大纲。DDD应用于建立模型上一个具体的方法叫做:DDM (Domain-Driven Modeling), 也称领域建模。

3、DDM具体能对产品经理及产品设计起到什么作用呢？

如果产品经理在需求分析及方案设计的初始阶段就采用DDM的方法，那么也许就能更好地和研发同事对接、协作，共同推动在服务层上完善初始设计，让系统具有更好的可扩展性，更能应对未来的新需求，新变化。

先举一个具体场景为例：

某项目的一次系统迭代需求评审会上，业务部门提出了新的需求点，要求增加一个新功能，产品经理提供了PRD、流程图等文档，并做了现场讲述，研发同学在评估及考虑实施方案的时候发现，该功能因为初始设计时完全没预料到，如果要新加这个功能，系统需要做的改动极大，甚至是需要大改底层框架结构及功能程序。
业务部门及产品经理都不解，为什么这么简单的一个功能，听起来实现却这么困难？不会是研发同学欺负咱们不懂技术又不想实施，所以找的借口吧？
也有可能产品经理懂相关的技术知识，深刻理解了研发同学的顾虑点。但是，却也犯了难，在修改需求与找到另外一个好方案之间踌躇。
其实这个场景体现了系统开发设计上一个永恒的困境，叫做：初始预料（构想）与现实变化之间的偏差。

当需求发生新增、变更，原有的系统肯定无法完全满足需求，于是我们只能做迭代，改动大的时候类似对衣服进行裁剪和局部拆解重缝，改动小的时候类似给衣服打打补丁。多次过后，就会面目全非。一段时间内，系统还能维持运转，支持现有不断增加的需求，一旦达到某个临界点，我们发现再也无法通过系统局部调整来继续维持，就只剩下一种办法来解决——完全重构。

虽然这是一个无法避免的问题，也无法根治，但并非完全没有改善的办法。

追根溯源，这种情况有可能是因为什么原因引起的？其中有一种可能是：在初始构想设计阶段，产品经理及业务部门更多关注应用表现层，研发人员更多聚焦于数据层，在数据层和应用表现层之间的服务层上不够完善，导致在数据及底层框架层上设计不完善，同时因为建模有所缺失，导致应对未来的新需求、新变化的可扩展性上不强。

3.1产品经理对需求的通常处理流程，

我们用一个具体的示意图来体现一下：

从图上就可以看出，在需求阶段，产品经理和业务部门更多关注的都只是应用层和表现层的东西，因为这两层主要包括了系统UI、前端功能（主要是系统界面上提供的使用功能，并非系统所有功能，因为前端功能由后端功能承载，只是所有功能的子集）、用户体验等。技术实现的具体方案的构想（策划）任务就主要留给了研发同事。但研发同事大多被应接不暇的开发任务缠身，能够用来做思考的时间有限，既要保证速度，又要保证质量，本身就是一个很高的要求，很容易无暇他顾。

此外，对内容更垂直细分以后，研发同事通常都更聚焦于某一个或几个点的工作，除非是经验丰富的高级研发人员或技术管理人员，普通的研发人员很难在繁重及窄小范围的工作上建立起系统层面的全局意识和对业务的高度整体化把握。而产品经理作为连接业务部门和技术部门的“中间人”，天生承担的职责其实就包括了需求梳理、思考总结、需求翻译转换这些工作。

前台系统（应用层），因为市场及客户需求、业务发展的多变性，本身就是多变的，而最底层的数据层则要求具有充分的稳定性。数据层很多时候更像是raw material，并不能直接成为组装成商品（成品）的部件，因此在raw material和商品之间，还需要有一层组装加工，这也就是服务层，它像一个生产商一样，最终供货给供应商（应用层）和销售商（表现层）。

3.2 产品经理对需求的处理流程（加入DDM方法）

加入DDM方法后，产品经理对需求的处理流程会变成如下：

那么DDM具体要怎么做呢？DDM的最终产出物是领域模型图，领域模型图主要包括三个最主要的内容：实体(Object，也称对象），动作(Action)，联系(Relationship)。在这三者之中，实体是最重要的，如果在建模过程中，实体尤其是核心实体有缺失，那么在系统的改动及迭代过程中，是极其容易碰到“牵一发而动全身”的状况的，因此DDM的实施，最重要的点就是条理清晰、结构完备地梳理相关的实体对象。

为什么说采用DDM的方法就能更多地避免未来需求变更系统不能支持或者需要大改呢，因为DDM最核心的要点是条理清晰、结构完备地梳理好该领域的所有实体。

实体是核心要件，如果在初始设计时，就能准确、完善地梳理出来，并且能够清晰地梳理他们彼此之间的联系，其实也就对应地梳理出来了当前及未来可能发生的场景及用例（User Cases)，能够尽可能地为未来打好基础。如果未来需求发生了没有预料到的变化，如果核心实体（对象）没有变化，那么也只是在动作、联系上做一些增改就可以实现。

核心实体类似建筑物的地基和承重桩，是“骨架”，“骨架”不变，“血”和“肉”的增减或者一些其他“小手术”并不至于伤筋动骨。

参考《从产品经理视角看DDD(领域驱动设计)思想及方法的效用》