关于核心DDD的相关的描述

前端之家收集整理的这篇文章主要介绍了关于核心DDD的相关的描述前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
其实,在之前的Nature框架中已经描述了不少,不过,这里,还是想完整的阐述一下其中的概念。
不过,肯定比较简略,如果真的要深入理解,还是要读《领域驱动设计》《实现领域驱动设计》这两本书。
好啦,接下来进入正题。
首先是关于聚合的内容。我们认为,相关联的一些事物,构成了一种叫做聚合的概念。比如,说到书,他就会有封皮,书名,每页书,作者等等等等。他们是聚合在一起的,说到书,就代表了那一堆东西。而书这个概念,我们则称之为聚合。如果把每种东西抽象成类和引用的关系,则总会有一个东西在最上层,表达着整体的概念,我们称之为聚合根。
那么,聚合是由什么构成的呢?值得一提的是,我们现在在说的聚合的概念,是一种结构性质的东西,与之相对的,它不是一种流程。
而构成聚合的构件,我们使用两个东西,实体,值对象。
什么是实体?什么是值对象?以我的语言能力,解释起来略困难了一点。这么说吧,实体的特点是,具有生命周期,在其生命周期之中,其内部状态可能会发生变化。但是,实体具有其唯一的标志,即使两个实体除了标志外所有属性均完全相同,我们也认为他们是两个实体。那么,这个标志是什么呢?这也是我最近才领悟的,这个标志,是值对象。说说值对象吧。值对象,如字面所述,是表示值的对象。它表示了一种值,那么,它就具备了这么几个特征。首先,它不会改变自己的一部分,或者说,它的状态不会变,因为它没有生命周期,所以,它没有状态。它要么,是这个值,要么是那个值,而不存在这个值可以被变为什么的说法。其次,如果两个值对象的所有状态都相等了,那么,它们就是同一个值,这个与实体能够形成鲜明的对比。
那么,为什么说实体的标志是值对象呢?曾经,我们的框架中,为了通用,将实体的标志,设置成了字符串。这可以满足唯一ID的需求,而且,也有最佳实践告诉我们,这样管理所有的表是好的。但是,在我以往的实践中就遇见过这种情况。有的记录是使用组合主键标志自己的唯一性的。当然,我们可以通过添加一个唯一ID的方式来使其统一,但,这引起了两个后果。首先,这增加了复杂度,其次,事情不是这样的,而却偏要这样实现,后面会遇到麻烦,其实,也是增加了复杂度。而在读《实现领域驱动设计》时,里面强调的,即使只是一个字符串,其实,它也是一个值对象。这是我们很容易混淆的一点,而值对象的引入,无疑,增加了我们对值这一概念的掌控。我希望在我这次的框架里,可以达到这一目的。最后说明一点,聚合根,一定是实体。
而聚合由实体和值对象构成,实体可以通过自身的方法改变自身的状态,而这些操作在聚合范围内,也代表着实现了聚合自身的业务。由此,聚合表达了自己所代表的业务的含义。
其实,这里,是有问题存在的。聚合是需要被持久化的东西,我们需要长期得跟踪其生命周期,改变其状态。那么,它的持久化,和读取或者说加载是怎么进行的呢?是由仓储进行的。仓储对聚合的持久化进行支持。提供了有限的几个操作:创建,保存,删除,通过标志加载。而正如仓储的字面意思,仓储,是一个仓库,做储备只用。而其中存储的东西,就是聚合。这里还有几个东西需要注意,既然,仓储是操作聚合的东西,那么,仓储,就不会在聚合内部被调用。而聚合之间,也是相互独立或者说是离散的。聚合和聚合之间,并无法直接相互操作,否则,他们就应该是一个聚合。
那,聚合之间的写作是怎么完成的呢?通过领域服务。那领域服务和聚合是什么样的关系呢?或者说,有什么相似或者不同呢?聚合,表达了领域中的一些结构,他们有属性,有生命周期,会被长时间的维护。而领域服务,也表达了领域中的一些结构,所不同的是,它没有属性,单纯的,提供服务。比如说,转账。如果账户是一个聚合的话,那么转账这个操作就会牵扯至少两个聚合。显而易见,在聚合内部是无法完成这个操作,这里需要一个服务来协调两个账户进行转账,而这个服务,我们则称之为领域服务。
在我们团队的实践过程中,老大最初定义的领域服务是面向用例的,而我认为的领域服务是构成领域的一部分,而面向用例的那部分,不过是类似门户的存在。不过,最近的一次实践老大妥协了,允许两种同时存在。而其实,面向用例的那部分,我在我之前的框架中,是定义为命令,与应用服务进行通信的。
那么,什么是应用服务呢?
其实,应用服务是独立于领域之外的,它是面向应用的,面向用例的。我们领域中的模型并不能直接在应用中使用,因为应用要的不一定是他,他不一定够。所以,在应用服务中,会把领域中的东西,组装成应用想要的东西,再丢给应用。应用服务,大概就是这样的用处,转发,同时,也能够防止领域被应用所腐蚀。
其实,这里,还有两个构造块我们没有说,领域事件,查询
先说说领域事件吧。还以上面转账的例子来说,这,其实,是发生了一件事情。事实上来说,它除了把钱从一个账户转到另一个账户外,还记录下了转账的流水。这是这个服务本身做的事情。而事实上,在之后,我们为了能够更加清晰的对系统进行监控,我们引入了日志。这里,是需要记录日志的。怎么记?修改原来的服务?可以。只是,似乎存在以下的问题。开闭原则,我们修改了原来的代码。单一职责原则,服务不仅要进行自己的业务,还要记录日志。高内聚低耦合,原来的服务需要认识并使用日志模块,看样子,日志模块会变得无所不在。那么,我们似乎看到,随着系统内容和复杂度的增加,这将会是一种灾难。可是,我们发现,事情并不是这个样子的。其实应该是,转账这件事发生了,因为这件事的发生,相关系统要进行对应的操作,比如,日志系统要记录日志。那么,发生的这件事,就是领域事件。领域事件的实现一般是发布订阅的模式来实现的,我们这里也是,这似乎是很自然的一件事情。
剩下的构造块,我称之为,查询。这个,是我在读了cqrs之后,引入的一个构造块。不了解的大家可以查一下cqrs的东西,以后有时间的话,我会整理一篇cqrs的文章。而cqrs采用事件溯源重构聚合,用领域事件更新查询源,供应用查询。而其解决的主要问题是,在经典DDD中,对业务的查询,是复杂的,低效的,因为应用需要的查询往往和领域自身的结构冲突,从而导致,连表查询,导致查询复杂度上升,效率降低。而起推崇以响应领域事件来维护一个供应用查询的数据源,而这个数据源中的数据,是我们为了满足应用的查询,而维护在那里的。值得注意的是,我们并没有定义新的构造块给这些数据,他们依然是,聚合,其实更接近dto,虽然有些不自然,但是,也算满足了我们的需要。另外,我们可以通过属性,来对这些数据进行查询


猜你在找的设计模式相关文章