实现DDD读书笔记1

什么是DDD

DDD是英文Domain-Driven Design的简称,在2004年由Eric Evans提出的一套软件设计的概念和方法论。

DDD并不是关于技术的,而是关于讨论、聆听、理解、发现业务价值的,而这些都是为了将知识集中起来。将领域专家引入到团队是大有好处的。

  • 领域专家不见得就知道所有的业务,他们也得学习。你向领域专家提出的问题有可能暴露出他们不知道的地方。
  • 领域专家不是一个职位,他可以是精通业务的任何人。
  • 领域模型是关于某个特定业务领域的软件模型。通常,领域模型通过对象模型来实现,这些对象同时包含了数据和行为,并且表达了准确的业务含义。

开发过程中,最大的鸿沟之一便存在于领域专家和开发者之间,通常,领域专家将关注点放在交付业务价值上,而开发者则将注意力放在技术实现上。

影响:领域专家和开发者虽一同工作,他们之间的协作也只是表面的。过程中产生了一种映射:将业务人员所想的映射到开发者所理解的。这样,软件便不能完全反映出领域专家的思维模型。这种鸿沟将增加软件的开发成本。随着开发者转到其他项目或离职,本应驻留在软件中的领域知识也就丢失了。

另一个问题,发生在多个领域专家之间存在分歧的时候。因为每个专家只熟悉某个或者某些特定领域。另外在某个领域找不到真正的专家也是可能的,此时,有人可能对领域有所了解,但他更像一个业务分析员。这些问题将导致相互矛盾的软件模型。

更糟的是,软件的技术实现可能错误地改变软件的业务规则。比如:ERP软件通常修改业务操作以满足某个特定用户的需求。解决方案才是主要的投入。

DDD的作用是简化,而不是复杂化。我们应该采用最简单的方式对复杂领域进行建模,而不是使问题变得更加复杂。

贫血领域对象有出现的原因:它反映了一种自然的过程式的编程风格。很多开发者都是学着示例代码做开发,通过情况下,示例代码只是尽可能简单的方式来展示某个特定的概念或API特性,而并不强调要遵循多好的设计原则。

如何DDD

DDD两大支柱:

  • 通用语言。在边界之内的每种领域术语、词组或句子,是团队自己创建的公用语言,团队中同时包含领域专家和软件开发人员。其都有确定的上下文含义,在边界之外,这些可能表示不同的意思。 通用词不是业务语言;不必完全采用工业标准术语;不是领域专家专用的。
  • 限界上下文(Bounded Context)。整个应用程序之内的一个概念性边界。

掌握通用语言的方法:

  • 同时绘制物理模型图和概念模型图,并标以名字和行为。虽然这些图并不是正式的设计图,但它们却包含了软件建模的某些方面。即使你的团队在使用统一建模语言UML来完成正式建模,也不要得意忘形,因为这样可能反而不利于团队的讨论,最终将阻碍通用语言的产生。
  • 创建一个包含简单定义的术语表。将你能想到的术语都罗列出来,包括好的和不好的,并注明好与不好的原因。在你给术语下定义时,你在不经意间就会创造出一些可重用的词汇,因为此时你使用的是领域中的通用 语言。
  • 如果你不喜欢术语表,可以采用其他类型的文档,但是记得将那些“不正式”的模型图也包含进去。同样,这里最终的目的也是发现通用语言中的术语和词组。
  • 由于团队中有些人工作在术语表上,还有些人工作在文档上,此时你需要找到团队的其他人员来检查你的成果。分歧肯定是有的,你应该对此有所准备。
  • 这样建立起来的模型不能直接用于指导开发,而只是建立通用语言的起步而已。此后改进之后的通用语言将反映到系统的源代码中。通用语言会过时,只有团队的交流和代码才能持续到最后,也只有这两者才能实时地反映通用语言。
  • 由于团队交流和代码才是对通用语言的持续表达,你应该试着抛弃那些模型图、术语表和文档。这样做的原因是,我们很难将项目文档和软件系统保持同步。对通用语言达成一致后,才开始着手开发。对领域模型的修改也将导致对应用层的修改。每个应用层的方法都对应着一个单一的用例流。

对通用语言的理解:

  • 通用意思是“普遍的”,或者“到处都存在的“。通用 语言在团队范围内使用,并且只表达一个单一的领域模型。
  • “通用语言”并不表示全企业、全公司或者全球性的万能领域语言。
  • 限界上下文和通用语言间存在一对一的关系。
  • 限界上下文是一个相应较小的概念,通常比我们起初的想象的要小。限界上下文刚好能够容纳下一个独立的限界上下文中所使用的通用语言。
  • 只有当团队工作在一个独立的限界上下文中时,通用语言才是”通用“的。
  • 虽然我们只工作在一个限界上下文中,但是通常我们还需要和其他限界上下文打交道,这时可以通用上下文映射图对这些限界上下文进行集成。每个限界上下文都有自己的通用语言,而有时语言间的术语可能有重叠的地方。
  • 如果你试图将某个通用语言运用到整个企业范围之内,或者更大的、跨企业的范围内,你将失败。

通用语言((ubiquitous language)实例

个人(实体):包含并管理用户的个人信息.包括名字和联系方式等。 激活租户:通过该操作激活一个租户,激活后再对租户的当前状态进行确认。 禁用租户:通过该操作禁用一个租户,在禁用一个租户时,用户可能还没有被认证。 认证服务:协调对用户的认证过程,首先需要保证他们所属的租户处于激活状态。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结