CN102981823A - 一种领域驱动开发插件系统 - Google Patents

Abstract

本发明适用于分布式网络系统开发领域，提供了一种领域驱动开发插件系统，所述系统包括：命令查询分离体系设计单元，用于分离领域模型中的业务过程与数据查询；领域缓存单元，用于领域对象的分布式内存缓存，实现领域的In-memory模型；消息代理单元，用于使领域与外界通信，并支持本地消息，以及分布式消息；消息模型设计单元，用于通过领域消息实现领域组件的信息交互，采用并发的事件驱动模式及AOP编程模型。本发明根据DDD理论及Spring框架，实现了一种基于领域消息驱动和内存建模的DDD插件Takia，使项目实施完全兼容DDD设计，同时基于消息的通信机制能有效的解耦系统模块，提高系统并发性能，在项目实施中更加合理高效。

Description

一种领域驱动开发插件系统

技术领域

本发明属于分布式网络系统开发领域，尤其涉及一种领域驱动开发插件系统。

背景技术

作为系统数据存储和分析的核心，数据库在信息系统中起着重要作用，目前的企业级应用平台开发和设计必须依赖于关系数据库，数据库在发挥巨大作用的同时，其模式结构也与主流的面向对象系统分析理论产生了较大的缝隙，随着系统规模不断增大，基于过程和事务脚本的系统分析方法已经不能满足业务需求。

基于OO技术构建的领域建模理论，为大规模业务系统分析提供了有力的理论指导，随着这方面理论不断地成熟，已经逐渐应用到各个领域的系统分析和构架中。领域建模(Domain Modeling-DM)的初期是基于对象关系映射的ORM(Object Relationship Mapping)技术，ORM通过数据库与对象的数据映射，解决了关系与对象的不匹配问题，让系统设计分析人员能够用纯粹的对象技术来解决领域问题。但是随着业务分析的深入，ORM产生的贫血对象模型由于行为能力的缺失，让系统又从对象模型退化为事务处理过程，与DM理论逐渐背离。随后为了避免贫血模型的弊端而出现的充血模型，将业务与数据全部合并到领域模型中，有很多框架都是在充血模型的理论基础上进行了大量实践(如ROR，Grails，Spring Roo等)，这些快速开发框架在小型项目上应用非常成功，因为其模板式的开发方式，强大的动态方法生成，以及快速脚手架(Scaffolding)等特性，让充血领域模型有了强大的功能。但是随着业务增长，领域对象急速膨胀，维护难度也在增加，使系统处于一个不可控的状态，并且业务和数据的领域整合使系统的结构变得模糊不清，所以这类框架始终没有成功的应用到大型项目开发中。

一种基于四色原型的领域开发模型Evans DDD，强调领域设计必须以业务为指导，Evans DDD不但弥补了ORM的对象行为缺失和生命周期问题，也通过领域聚合和分解有效地解决了充血模型随着领域的扩大而臃肿的缺陷，为大型系统设计和开发提供了一个合理的解决途径。由于Evans DDD的设计理念比较灵活，系统开发和设计人员对该理论进行了很多的实践并取得了较多成果，但是始终没有一个统一的底层技术构架来支持该模型。这不但给该理论的推广造成了极大的障碍，没有统一的构架支持，系统开发人员也很难将系统分析转换为编码，大大降低了系统的实施效率。同时现有的框架体系基本是以数据库为核心的分层结构，也为DDD的实践造成了很大的障碍，一些全新的框架由于不能很好的兼容以前的遗留系统，也很难得到推广。

DDD是完全基于内存的业务对象建模(In-Memory)方法，但是在项目实施过程中，目前的开发框架均依赖于关系数据库系统，ORM虽然在数据库与业务系统之间进行了桥接，但只支持贫血模型且对象生命周期无法DDD匹配，造成系统实施过程与设计不相符。现有的DDD框架不能完全覆盖系统业务，也不成熟稳定，无法应用于实际项目的开发。

发明内容

本发明实施例提供一种领域驱动开发插件系统，旨在解决现有技术中JavaEE的分层构架出现领域失配、性能低下及DDD理论与实践不兼容的问题。

本发明实施例是这样实现的，一种领域驱动开发插件系统，所述系统包括：

命令查询分离体系设计单元，用于分离领域模型中的业务过程与数据查询；

领域缓存单元，用于领域对象的分布式内存缓存，实现领域的In-memory模型；

消息代理单元，用于使领域与外界通信，并支持本地消息，以及分布式消息；以及

消息模型设计单元，用于通过领域消息实现领域组件的信息交互，采用并发的事件驱动模式及AOP编程模型。

本发明实施例根据DDD理论及Spring框架，实现了一个基于领域消息驱动和内存建模的DDD插件Takia，使项目实施完全兼容DDD设计，同时基于消息的通信机制能有效的解耦系统模块，提高系统并发性能，在项目实施中更加合理高效。

附图说明

图1是本发明实施例提供的领域驱动开发插件系统的结构图；

图2是本发明实施例提供的Takia DDD整体构架模型的结构图；

图3是本发明实施例提供的可伸缩构架的变迁趋势图；

图4是本发明实施例提供的卫星结构模型的结构图；

图5是本发明实施例提供的Takia DDD编程模型的流程图；

图6是本发明实施例提供的命令查询分离体系设计单元的结构图；

图7是本发明实施例提供的模型创建流程设计模块的实现流程图；

图8是本发明实施例提供的模型更新流程设计模块的实现流程图；

图9是本发明实施例提供的模型删除流程设计模块的实现流程图；

图10是本发明实施例提供的模型查询流程设计模块的实现流程图；

图11是本发明实施例提供的消息代理单元的结构图；

图12是本发明实施例提供的JDK-Future消息模型设计模块的业务流程图；

图13是本发明实施例提供的Disruptor消息模型设计模块的业务流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例基于Spring框架，实现了一种基于领域消息驱动及内存建模的DDD插件Takia，使项目实施完全兼容DDD设计，同时基于消息的通信机制能有效解耦系统模块。

图1示出了本发明实施例提供的领域驱动开发插件系统的结构，详述如下：

命令查询分离体系设计单元12分离领域模型中的业务过程与数据查询。

在本发明的实施例中，基于Takia的业务过程由命令总线和查询总线构成，该查询分为模型查询及组合查询，均支持分页查询。

在本发明的实施例中，命令查询分离体系设计单元12包括：模型创建流程设计模块121，模型更新流程设计模块122，模型删除流程设计模块123以及模型查询流程设计模块124。

模型创建流程设计模块121根据用户数据创建模型对象和相关值对象。

模型更新流程设计模块122根据用户数据修改已经存在的模型对象和相关值对象。

模型删除流程设计模块123根据用户数据删除已经存在的模型对象和相关值对象。

模型查询流程设计模块124根据查询条件查询模型数据列表。

领域缓存单元13根据领域对象的分布式内存缓存，实现领域的In-memory模型。

消息代理单元14使领域与外界通信，并支持本地消息，以及分布式消息。

消息模型设计单元15通过领域消息实现领域组件的信息交互，采用并发的事件驱动模式及AOP编程模型。

在本发明的实施例中，领域消息模型根据标准的生产者一消费者设计模式构架。

在本发明的实施例中，消息模型设计单元15包括：JDK-Future消息模型设计模块151以及Disruptor消息模型设计模块152。

JDK-Future消息模型设计模块151根据Future消息模型运行消息监听器。

在本发明的实施例中，Future消息模型基于JDK的Concurrent包实现，由线程池和同步组件组成，若使用异步模式，则线程池运行消息监听器，若使用同步模式，则同步组件将消息监听器放入当前线程中执行。

Disruptor消息模型设计模块152根据Disruptor消息模型同时运行多个消息处理器，独立设置处理结果。

在本发明的实施例中，Disruptor消息模型基于并发编程框架Disruptor实现，采用全异步模式且支持1∶N消息模式，核心结构由输入区域和输出集合组成。

作为本发明的一个优选实施例，该领域驱动开发插件系统还包括卫星结构模型设计单元11。

卫星结构模型设计单元11通过与核心领域的消息交换实现业务逻辑，且以实体领域为核心。

在本发明的实施例中，领域驱动开发插件系统以实体对象、值对象、聚集，以及领域事件为基础，采用分布式缓存实现领域的In-Memory模型。

在本发明的实施例中，该系统采用以领域容器为核心的辐射结构，对领域缓存及领域消息均采用SpringAOP及Auto-Proxy的透明机制实现。

图2示出了本发明实施例提供的Takia DDD整体构架模型的结构，详述如下：

该构架的底层为Spring业务框架，Hibernate ORM框架及数据库管理系统，对于常规模型的开发人员来说比较熟悉，能够容易的完成开发过渡。

在本发明的实施例中，Takia插件构架于Spring业务框架之上用以提供领域建模支持，在系统设计时，业务模块被划分成多个领域进行分散式并行开发，一个领域一般由领域对象(Domain Object)，值对象(Value Object)，服务(UsecaseService)和仓储(Repository)等组件构成。领域的外围是Takia提供的透明缓存和消息服务，这些服务通过基于Annotation的领域模型配置，使用AOP方式注入到相关的领域对象中，缓存用于提升领域对象的性能，消息用于降低系统及模块之间的直接耦合。Takia在设计时支持多种缓存实现，默认为EhCache以支持集群结构。

图3示出了本发明实施例提供的可伸缩构架的变迁趋势，详述如下：

在传统的分层构架中，由于贫血对象模型没有业务处理能力，所以业务分散在服务和控制权里面，随着业务系统的扩大，这种分散的业务代码会导致复用率迅速下降，代码数量的快速膨胀，对升级和维护造成非常大的困难。而基于DDD构架使用的富领域模型，让核心业务和数据集中到领域模型中，前端控制器和服务变的越来越薄，基本只负责领域模型的协调和调度工作，不直接参与业务，系统的扩展演变为业务即领域模型的扩展，由于领域模型具有很高的可复用性，所以系统的升级维护比较容易，代码膨胀速度缩小，系统可伸缩性提高。

图4示出了本发明实施例提供的卫星结构模型的结构，详述如下：

在本发明的实施例中，Takia的核心领域为聚合的领域模型(以Model标注)，以实体对象为中心，值对象作为实体的依赖对象。核心领域构成业务恒星，而系统的领域服务(Domain Service)，仓储，切面服务(Aspect)，以及界面(UI)等组件成为核心领域的卫星，他们之间不直接交互，而是通过与核心领域的消息交换来实现业务逻辑。

根据这个设计，传统的分层开发模型必须要做出调整，客户端的请求到达服务器以后，MVC控制器作为DDD的Facade使用，用于从缓存中获取领域实体对象或者构建新的领域对象，而业务逻辑不再通过直接的服务调用，通过领域对象之间以消息的方式相互作用来完成，一个领域通过领域服务对象来组织整体业务，领域能实现自身的领域服务，这些交互均通过领域事件来触发，信息通过领域消息来传递。

在本发明的实施例中，Takia对领域缓存和领域消息均采用Spring AOP和Auto-Proxy的透明机制实现，对业务组件零入侵，基本对现有开发方式不造成影响。

图5示出了本发明实施例提供的Takia DDD编程模型的流程，详述如下：

在本发明的实施例中，Takia DDD替换了Spring原有的业务层和持久层，采用以领域容器为核心的辐射结构。在该模型中，Spring UI和MVC组件充当

使用，当截获用户请求以后，会对请求进行解析和封装，形成DDD的语义形式，传递给Takia DDD，Takia首先从领域模型容器(Model Container)中提取该请求所对应的聚合根(Aggregation Root)对象，通过对象图遍历(ObjectGraph Iteration)找到请求所需要的业务实体(Entity)对象，模型容器中的实体对象均为富对象模型(Rich Model)。在业务处理过程中，实体可以直接调用自己的相关方法完成业务处理，将结果返回给表现层组件，然后回馈给客户端，整个处理过程结束。

图6示出了本发明实施例提供的命令查询分离体系设计单元的结构，详述如下：

在本发明的实施例中，命令总线负责处理领域的业务过程。

当客户端(Client)需要完成一个业务逻辑时，将一个命令通过网络发送到后端业务系统，业务系统接收请求后根据命令查找命令处理器(CommandHandler)，命令处理器根据命令对象信息，从Takia的领域容器(DomainContainer)中获取业务相关的领域根对象(Root)并获取到目标领域对象，由领域对象调用相关的领域服务(Domain Service)完成指定业务过程并即时向客户端返回处理结果。领域服务同时将相关业务信息作为领域消息(DomainMessage)，通过消息总线(Message Bus)发送到事件处理器(Event Handler)，通过事件处理器与服务，仓储对象的交互，实现相关数据存储。

在本发明的实施例中，查询总线专门负责数据查询工作，与命令总线之间没有任何相互作用。

在查询模式下，查询参数通过网络传输到前端统一的查询门面(QueryFacade)，转换成统一的查询条件后传入Takia的查询层，通过对底层JDBC及Hibernate等框架的统一封装，实现数据查询，并提供查询缓存以提高整体查询性能。

在本发明的实施例中，查询分为模型查询和组合查询两种方式，均支持分页查询。模型查询采用的是ID块查询方式，只查询出记录ID分块，然后与模型容器交互获取查询数据，并将查询结果转换成DTO列表返回给客户端；组合查询针对多表多条件统计查询进行设计，直接对数据库表或视图进行查询并生成内存的二维数据结构返回客户端。

在本发明的实施例中，Takia基于CQRS的整体构架，让查询完全不用阻塞在数据更新操作上，可以保证查询的独立性并提高数据读性能；而业务逻辑由于引入了事件驱动和领域消息机制，通过异步方式进行数据更新，实现非阻塞的业务处理方式，有效提高了应用系统的业务吞吐量和整体性能。

图7示出了本发明实施例提供的模型创建流程设计模块的实现流程，详述如下：

在本发明的实施例中，模型的创建是指根据用户数据创建一个模型对象和相关值对象的过程。

用户通过UI，将数据通过Form传输到后台服务器，服务器在获取到客户端Form数据以后，Takia首先使用模型容器创建一个模型的原型对象，再对该对象进行增强(Enhancement)，完成模型和值对象的依赖关系注入，以及模型的动态代理，形成一个初始化的领域对象。然后将Form参数装配到领域对象中并进行数据验证，验证通过后，模型创建完成，Takia会将该对象放入模型容器供其他业务过程使用，再清除该模型对象类型所对应查询缓存，以保持查询系统一致性。最后，领域对象通过Takia的消息总线将数据传递给服务和仓储对象，完成数据与数据库的数据保存同步，并同时向客户端返回模型对象创建成功的信息。若在过程中出现任何错误，均向客户端发送错误报告，终止模型创建过程。

图8示出了本发明实施例提供的模型更新流程设计模块的实现流程，详述如下：

在本发明的实施例中，模型的更新是指根据用户数据修改一个已经存在的模型对象和相关值对象的过程。

用户通过UI，将修改数据通过Form传输到后台服务器后，Takia首先从Form数据中提取出需要修改的模型ID，再根据ID到元数据映射表中查询模型类型，创建模型缓存主键(Model Key)和模型加载器(Model Loader)。模型容器使用这两个组件获取ID所对应的模型对象(该对象可能是已经存在于缓存的，也有可能是从模型加载器中加载的新数据)，然后将Form数据更新到模型对象中，完成内存数据更新过程。同时，模型对象通过Takia的消息总线将数据传递给服务和仓储对象，完成数据与数据库的数据更新同步，并向客户端返回模型对象修改成功的信息。若在过程中出现任何错误，均向客户端发送错误报告，终止模型更新过程。

图9示出了本发明实施例提供的模型删除流程设计模块的实现流程，详述如下：

在本发明的实施例中，模型的删除是指根据用户数据删除一个已经存在的模型对象和相关值对象的过程。

用户通过UI，将修改数据通过Form传输到后台服务器后，Takia首先从Form数据中提取出需要修改的模型ID，再根据ID到元数据映射表中查询模型类型，创建模型缓存主键和模型加载器。模型容器使用这两个组件获取到ID所对应的模型对象(该对象可能是已经存在于缓存的，也有可能是从模型加载器中加载的新数据)。然后在容器中删除该对象，最后模型对象通过Takia的消息总线将数据传递给服务和仓储对象，完成数据与数据库的数据删除同步，并向客户端返回模型对象删除成功的信息。若在过程中出现任何错误，均向客户端发送错误报告，终止模型删除过程。

图10示出了本发明实施例提供的模型查询流程设计模块的实现流程，详述如下：

在本发明的实施例中，模型查询是指根据查询条件查询模型数据列表的过程。

组合查询没有与模型的交互和DTO转换，其余步骤相同，这里不再单独描述。用户通过UI，将查询条件通过Form传输到后台服务器后，Takia首先使用查询门面(Query Facade)和查询上下文工厂(Query Context Factory)将查询条件转换为查询上下文(Query Context)。然后将上下文传递给查询包装器(Query Wrapper)进行条件查询，查询包装器使用ID块查询，返回该查询条件下所对应模型对象的ID分页列表(Identifier Paged List)，Takia的模型容器自动根据这个分页列表将ID转换为模型对象，然后模型对象通过消息总线对所查询属性进行必要的数据懒加载(Lazy Loading)，并转换为DTO分页列表(分布式系统需要使用，普通网页访问可以省略该步骤，直接返回模型对象列表)。最后服务器前端的视图渲染器(View Renderer)根据DTO分页列表呈现用户视图后发送回客户端进行显示。

在Takia中，支持模型缓存的方式之一是直接使用ModelContainer接口来实现领域对象缓存和领域对象(实体领域对象)的创建，ModelContainer的默认实现为DefaultCachingModelContainer类，ModelContainer的对象引用已经集成在webbiz的Controller基础类中，可以直接引用，其中关键的方法说明如下：

void addModel(ModelKey modelKey，Object model)：往缓存中放入模型对象，ModelKey为缓存Key，由模型的类和ID构成。

void addModel(ModelKey modelKey，Object model，boolean enhance)：同上面方法，enhance参数为true，表示自动把实体的依赖关系进行注入。

Object getModel(ModelKey modelKey)：根据一个key从缓存中获取模型对象，如果没找到返回null。

Object getModel(ModelKey modelKey，ModelLoader modelLoader)：同上面方法，如果没找到模型对象，则调用modelLoader对象进行加载。

Object getModel(ModelKey modelKey，ModelLoader modelLoader，booleanrequired)：同上面方法，required为true表示modelLoader不能返回空对象。

Object removeModel(ModelKey modelKey)：根据key从缓存中删除一个模型对象。

void identifiersToModels(MutablePagedList<Object>pagedList，Class<？>modelClass，ModelLoader modelLoader)：查询用接口，将id列表转换为实际的对象列表。

<T>List<T>identifiersToModels(List<Object>identifiers，Class<T>modelClass，ModelLoader modelLoader)：同上面方法一致，只是没有分页信息。

<T>T makeModel(Class<T>modelClass)：创建一个指定类型的模型对象。

<T>T enhanceModel(T model)：将一个对象从普通对象增强为领域对象，增加事件支持和依赖关系注入。

在Takia中使用缓存还有一种AOP方式如下：

该模式下缓存的删除需要通过ModelContainer手动进行。

同时对缓存的管理还可以使用Spring的注解缓存：

图11示出了本发明实施例提供的消息代理单元的结构，详述如下：

本地消息用于同一虚拟机集群的模块之间的数据交换，例如与领域内部的对象和服务，仓储通信，访问其他领域，及使用系统的公共服务等；分布式消息用于访问外部系统。由于消息代理对领域进行了充分解耦，可以很方便的使用测试驱动开发(TDD)方式完成业务系统开发，独立的领域很容易实施单元和集成测试。对于需求的变更，可以方便的修改、删除现有领域或增加新领域，并通过消息代理进行系统集成。

图12示出了本发明实施例提供的JDK-Future消息模型设计模块的业务流程，详述如下：

领域消息(Domain Message)作为消息生产者(Domain Object)和消息消费者(Message Listener)之间的桥梁，用来传递信息，由事件源(Event Source)和Future结果事件(Future Result Event)组成。结果事件中包含了结果对象，事件元数据配置和一个Future Task对象，Future Task作为简单的内存障(Memory Barrier)，与通道执行器(Channel Executor)配合使用来保证消息的一致性。

在本发明的实施例中，由于受到Future机制的限制，在Future模式下只支持1∶1的生产者和消费者通信模式。

消息过程由领域对象(Domain Object)发起，通过调用领域事件集合创建一个领域消息(Domain Message)对象后，领域对象将事件源传递给领域消息(事件源即领域对象传递给消息监听器的信息)。然后领域事件集合会通知消息拦截器(Message Interceptor)对领域消息的结果对象进行初始化，完成消息创建过程。之后消息拦截器调用事件消息发火器发送消息，事件消息发火器将Future消息的发送委托给Future发火器，根据消息配置从IoC容器中获取消息监听器组件后和领域消息一起放入通道执行器中运行。

在本发明的实施例中，对于同步消息，通道执行器使用同步组件在当前线程中运行消息监听器；对于异步消息，通道执行器会将消息监听器放入ThreadPool中执行。消息监听器可以在业务完成后对领域消息设置结果对象(EventResult)，最后作为消息生产者的领域对象可以通过领域消息的设置结果对象方法获取消息监听器处理结果，该方法可以被多次调用，并返回同一结果。在该模式下，领域消息的Future Task会保证结果的可用性和一致性。

图13示出了本发明实施例提供的Disruptor消息模型设计模块的业务流程，详述如下：

在Disruptor模式下，领域消息由事件源(Event Source)及Disruptor结果事件(Disruptor Result Event)组成，结果事件中包含事件元数据配置和一个事件处理器(Value Event Processor)对象，事件处理器用于读写结果输出区域的环形缓冲区(Ring Buffer)。

在本发明的实施例中，Disruptor模式下支持1∶N的生产者和消费者主体订阅模式(Topic Subscription)。

与Future模式的流程类似，Disruptor的消息过程同样由领域对象发起，通过调用领域事件集合创建一个领域消息对象后，领域对象将事件源(EventSource)传递给领域消息(事件源即领域对象传递给消息处理器集合的信息)。然后领域事件集合会通知消息拦截器(Message Interceptor)对领域消息的结果对象进行初始化，完成消息创建过程。之后消息拦截器调用事件消息发火器发送消息，事件消息发火器根据消息的主题创建输入区域的Disruptor对象，并从IoC容器中获取该主题所对应的消息处理器列表，并放入输入Disruptor中执行，由于Disruptor是完全异步的，所以消息处理器的执行完全不会阻塞领域对象的其他业务操作。消息处理器的处理结果通过值事件处理器设置到输出Disruptors中，最后作为消息生产者的领域对象可以通过领域消息的设置事件结果方法获取消息处理器集合的处理结果。由于支持多消息处理器模式，所以设置事件结果方法的多次调用可以得到不同处理器的依次处理结果，但是需要注意的是若次数大于消息处理器所产生的结果数，设置事件结果方法将被挂起。

他们两者使用上没有本质区别，下面介绍在开发中涉及到的几个类：：

Send注释消息发布者(Message-Publisher)，里面有四个属性：value表示主题名即产生的事件名称，action属性只能在future模式下使用，表示所调用接受者的方法，asyn属性是一个同步异步开关，只能在future模式下使用，type属性是消息模式选择，目前只可以设置disruptor和future两个值，默认为disruptor。

在future模式下只支持1∶1的消息发布接收模式，Spring的Component，Service注解的组件均可以接收到Send发出的消息。

在disruptor模式下为了支持1∶N，消息接收者多出了两个注解：

OnEvent注释在接收消息的方法上面，value属性跟Send的value属性对应；Consumer注释在接受者的类上面，value属性跟Send的value属性对应。

DomainMessage类是消息实体，在消息的发布者与接受者之间传递输入参数和结果，发送者通过DomainMessage的eventSource属性来设置事件源对象，产生一个消息可以直接使用构造函数：

new DomainMessage(eventSource)

这个eventSource对象可以在接收者中获到，并通过它进行业务处理，处理结果，接收者同样可以通过DomainMessage进行设置，如下：

DomainMessage.setEventResult(result)

消息处理完后，发送者可以通过DomainMessage.getEventResult()获取到接收者的处理结果。

例如Jdk Future和Disruptor下的消息机制开发：

Jdk Future模式下(1∶1模式)：

消息发送者(Message Publisher)：

Jdk Future模式下的消息接受者：

Disruptor模式下(高并发异步模式，1∶N)：

消息发送者(Message Publisher)：

消息接收者支持以下方式：

1)Consumer注解方式

2)OnEvent注解方式，支持以下四种参数形式的方法Dispatch：

3)若没有找到Consumer则会扫描Component组件的名字，作为fallback：

在这两种模式下，若消息未找到接收组件，均会抛出异常报错，终止该消息的publish过程。

Takia管理Ring Buffer的策略是为每一个Topic创建一个Input Disruptor实例，为每一个Domain Message对象创建一个独立的Output Disruptor实例，所以一个Input Disruptor会对应多个Output Disruptors。他们之间完全独立互不影响，为了在性能和资源占用上取得平衡，Takia默认使用Disruptor的Blocking等待策略。

本发明实施例根据DDD理论及Spring框架，实现了一个基于领域消息驱动和内存建模的DDD插件Takia，使项目实施完全兼容DDD设计，同时基于消息的通信机制能有效的解耦系统模块，提高系统并发性能，在项目实施中更加合理高效。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种领域驱动开发插件系统，其特征在于，所述系统包括：

命令查询分离体系设计单元，用于分离领域模型中的业务过程与数据查询；

领域缓存单元，用于领域对象的分布式内存缓存，实现领域的In-memory模型；

消息代理单元，用于使领域与外界通信，并支持本地消息，以及分布式消息；以及

消息模型设计单元，用于通过领域消息实现领域组件的信息交互，采用并发的事件驱动模式及AOP编程模型。

2.如权利要求1所述的系统，其特征在于，所述分离领域模型中的业务过程由命令总线和查询总线构成，所述分离领域模型中的数据查询分为模型查询及组合查询，均支持分页查询。

3.如权利要求1所述的系统，其特征在于，所述命令查询分离体系设计单元具体包括：

模型创建流程设计模块，用于根据用户数据创建模型对象和相关值对象；

模型更新流程设计模块，用于根据用户数据修改已经存在的模型对象和相关值对象；

模型删除流程设计模块，用于根据用户数据删除已经存在的模型对象和相关值对象；以及

模型查询流程设计模块，用于根据查询条件查询模型数据列表。

4.如权利要求1所述的系统，其特征在于，所述领域消息模型根据标准的生产者-消费者设计模式构架。

5.如权利要求1所述的系统，其特征在于，所述消息模型设计单元具体包括：

JDK-Future消息模型设计模块，用于根据Future消息模型运行消息监听器；以及

Disruptor消息模型设计模块，用于根据Disruptor消息模型同时运行多个消息处理器，独立设置处理结果。

6.如权利要求5所述的系统，其特征在于，所述Future消息模型基于JDK的Concurrent包实现，由线程池和同步组件组成，若使用异步模式，则线程池运行消息监听器，若使用同步模式，则同步组件将消息监听器放入当前线程中执行。

7.如权利要求5所述的系统，其特征在于，所述Disruptor消息模型基于并发编程框架Disruptor实现，采用全异步模式且支持1∶N消息模式，核心结构由输入区域和输出集合组成。

8.如权利要求1所述的系统，其特征在于，所述系统还包括：

卫星结构模型设计单元，用于通过与核心领域的消息交换实现业务逻辑，核心为实体领域。

9.如权利要求1所述的系统，其特征在于，所述系统以实体对象、值对象、聚集以及领域事件为基础，采用分布式缓存实现领域的In-Memory模型。

10.如权利要求1所述的系统，其特征在于，所述系统采用以领域容器为核心的辐射结构，对领域缓存及领域消息均采用Spring AOP及Auto-Proxy的透明机制实现。

Images