[译文]Domain Driven Design Reference(四)—— 柔性设计 (2)

  在适当的情况下,在定义操作时让它返回类型与其参数的类型相同。如果实现者的状态在计算中会被用到,那么实现者实际上就是操作的一个参数,因此参数和返回值应该与实现者有相同的类型。这种操作就是在该类型的实例集合中的闭合操作。闭合操作提供了一个高层接口,而不会引入对其他概念的依赖。

  这种模式通常应用于值对象的操作。因为一个实体的生命周期在领域中具有重要意义,所以你不能创造一个新的实体来回答一个问题。也有一些操作在实体类型下闭合。可以向其主题对象请求一个属性对象并取回另一个属性。但总的来说,实体并不是那种适合成为计算结果的概念。所以,大多数情况下,这是一个寻找值对象的机会。

  你有时会陷入这种模式的一半。参数与实现者匹配,但返回类型不同,或者返回类型与接收者匹配,参数不同。这些操作并不是闭合的,但是他们给与了思考闭合的一些优势的想象空间。

 

声明式设计

  在程序软件中不可能有真正的保证。仅以一种逃避断言的方式命名,代码可能会产生额外的副作用而这些副作用并没有被排除在外。无论我们的设计如何以模型为导向,我们仍然最终编写程序来产生概念上的交互效果。并且我们花费大部分时间在编写样板代码上,而这些代码并没有实际增加任何意义或者行为。本章中的释意接口和其它模式有所帮助,但是它们不可能给传统的面向对象提供形式上的严谨。

  这些是声明式设计背后的动机。这个术语对很多人来说意味着许多东西,但通常它指示一种编写一个程序或者程序的某个部分的方式,作为一种可执行的规范。对属性的非常精确的描述实际控制着软件。在它的各种形式中,可以通过反射机制或编译时通过代码生成来完成(基于声明自动生成传统代码)。这种方法允许其他开发人员以表面价值接受声明。这是一个绝对的保证。

  如果开发人员有意或无意地绕过它们,很多声明式方法可能会被破坏。当系统难以使用或限制过多时,这很可能发生。每个人都必须遵守框架的规则才能获得声明式编程的好处。

 

一种声明式的设计风格

  一旦你的设计有释意接口,无副作用函数和断言,你就会进入声明式领域。声明式设计的许多好处都是在您具有可交流其含义的可组合元素,并且具有特征或明显效果,或根本没有可观察效果时获得的。

  柔性设计可以使客户端代码使用声明式的设计风格成为可能。为了说明这一点,下一节将介绍本章中的一些模式,以使规范更加灵活和声明性。

 

图上的形式主义(形式化的绘画)

  从零开始创建一个严格的概念框架是你每天都不能做的事情。有时在项目的生命周期中,您会发现并改进其中的一个。但是你可以经常使用和调整那些长期在你的领域或其他领域建立起来的概念系统,其中一些已经经过了几个世纪的精炼和提炼。例如,许多商业应用程序都涉及会计。会计定义了一套完善的实体和规则,可以轻松适应深层模型和柔性设计。

  有许多这样的形式化的概念框架,但我个人最喜欢的是数学。让人惊讶的是,在基本算法上做一些改变是多么有用。很多领域包括数学。寻找它。挖出来。专业的数学是干净的,可以通过清晰的规则组合起来,并且人们发现它很容易理解。

  在本书的第8章讨论一个真实世界的例子“Shares Math”,领域驱动设计。

 

概念轮廓

  有时人们会为了灵活的组合而砍掉一些功能。有时候他们会把它封装得很复杂。有时他们会寻求一致的粒度,使所有类别和操作达到相似的程度。这些都是过于简单化的,不像一般规则那样有效。但是他们通过基本问题来激发。

  当模型或设计的元素被嵌入到一个整体结构中时,它们的功能会被复制。外部接口并不表示客户端可能关心的所有内容。他们的意思很难理解,因为不同的概念是混合在一起的。

  相反,分解类和方法可能会使客户端无意识去复杂化,迫使客户端对象了解如何将小块组合在一起。更糟糕的是,一个概念可能完全丧失。铀原子的一半不是铀。当然,重要的不是颗粒度的小大,但这只是颗粒度的来源。

  因此:

  将设计元素(操作、接口、类和聚合)分解为内聚单元,同时考虑到您对领域重要分支的直觉。通过连续的重构观察核心的变化和稳定性,并寻找解释这些切分方式的基本概念轮廓。对比模型与领域一致的方面,首先让它成为一个可行的知识领域。

  基于深度模型的柔性设计产生了一组简单的接口,这些接口逻辑上可以在通用语言中作出合理的声明,并且没有无关选项的干扰和维护负担。

 

 

作者:Zachary_Fan
出处:

 

 

如果你想及时得到个人自写文章的消息推送,欢迎扫描下面的二维码~。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wsxjpp.html