我对域驱动设计域建模的看法

我对域驱动设计域建模的看法

在前两节中，叙述仅集中在一个句子上: 领域驱动设计的核心在领域模型中，而领域建模的核心在领域业务中. 那么如何进行域建模？掌握能力没有捷径可走，但是没有办法遵循. 下面将解释领域业务和建模的两个方面.

做领域建模，首先要做的是掌握领域业务知识，那么领域业务知识从何而来？上一章说，并非所有从事软件研发的工程师都来自本科课程的学生. 一些与计算机相关的学科自然会携带领域业务知识，例如GIS. 这些的学生都从事该的软件开发，他们已经在该领域具有知识，他们在进行需求研究，分类和内部交流时使用通用语言. 每个人都对模型应该达成共识.

对于当前Internet软件的开发，我们面临的业务领域可能是一个崭新的领域. 它是产品经理根据用户痛点设计的全新软件工具. 这时，我们应该如何建立我们的领域模型呢？领域模型必须是一个名词，然后我们可以以此为起点，枚举软件使用的所有名词，然后对这些名词进行分类，然后从分类为同一类型的许多名词中提取核心名词，然后绘制核心类别中名词与其他名词之间关系的图表. 最后，对类别中名词所拥有的动词进行抽象.

以支付系统的用户信息为例，第一步列出所有名词并将其分类；第二步提取每组关键字；第三步，提取各个领域中的动词，如下所示:

域域模型划分应确保业务的高凝聚力和低耦合性，划定域边界，确保业务逻辑在域模型内尽可能多，并尽可能减少域模型之间的业务交互，以确保域模型的划分该过程涉及尽可能少的域模型.

在域模型的构建过程中，业务专家/产品经理必须保持实时通信并在模型组件上保持统一的语言. 最近，我正在阅读金字塔原理，它涉及归纳思维和演绎思维. 最初的思维方式是演绎思维，它决定了我们经常基于过程来思考问题，而面向对象的建模所需要的是归纳思维. 如果我们使用面向对象的思想开发和构建软件，并且业务专家/产品经理根据业务流程与我进行交流，那肯定是错误的.

进行领域驱动的设计时，必须召集领域专家/产品经理在领域建模中共同讨论设计，以确保参与产品设计，开发和测试的所有人员以统一的领域通用语言级别进行交流. 例如，产品经理将告诉我们如何获取登录密码，如何进行第一步，如何进行第二步领域建模，如何进行第三步以及最终结果是什么. 基于域模型的通用语言应该是登录密码应具有检索密码的作用. 完成此操作需要第一步，第二步和第三步.

对于长期以来一直基于过程模式进行软件开发的工程师而言，向领域建模的过渡需要适应过程. 基于流程的开发和基于模型的开发是两种完全不同的思维方式. 我们需要集成封装在对象中而不是流程中的代码的业务逻辑. 对于使用spring之类的框架构建的系统领域建模，整个项目使用单例模式，全屏事务脚本，并且所需的代码逻辑很方便. 但是，在基于域模型的代码中，任何业务逻辑都需要小心处理. 业务被封装在最合适的域对象中，因为逻辑只能在整个项目中的一个地方存在，并且有必要确保业务逻辑具有尽可能少的跨域模型. 由于使用领域模型进行开发非常麻烦，因此为什么要使用领域模型进行开发？因为域模型比事务脚本可以更好地管理大型业务逻辑.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-229250-1.html