`
nfxu
  • 浏览: 4220 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

矛盾:充血的领域模型和Web服务器装载的spring context

阅读更多
情况是这样的:

1 一个架构为struts2,spring,hibernate的web应用。
2 采用充血的领域模型,即领域bean里含有一些简单的业务逻辑,例如CRUD之类的操作。这些操作需要hibernate的session factory以便访问数据库。
3 Spring中定义了session factory,因此可以将它注入任何需要的地方。同样也可以注入领域bean和service类中。

但问题是领域bean因为比较小(其实也不小,如果充血的话),一般用new的方式生成,因此无法从Spring中获得session factory。像service类比较大,一般是从Spring中获得实例,因此注入了session factory,没有问题。

如果是失血模型的话,领域类里只有getter 和setter方法,因此不存在注入session factory的问题。

当然我也可以用BeanFactory.getBean("beanName")的方式获得session factory,但这样就不够好看了,出现了applicationContext和BeanFactory并存的局面,感觉不优雅( 我现在的Spring是通过web.xml在Web服务器启动时载入的,因此是application context)。

难道大家不用充血模型?

在Spring reference的3.9. Glue code and the evil singleton中,似乎有些提示,但不怎么明白。
分享到:
评论
40 楼 zwj_soft 2009-02-09  
让Domain依赖仓储,不妥吗?
39 楼 lovingprince 2009-01-13  
其实仔细理解 领域模型的概念就知道了。 service服务层是协调domain对象之间的关系的。相当于一个facade.

遇到你这种情况,可以采用这种方式

service1-->invoke domain
假设domain中要使用到service2.
那么应该通过domain的方法传入,即将service2注入service1,然后通过参数传递到domain中

service1{
method(){
   domain.method1(service2Instatnce ,parameters);
}

如果domain要使用自身service的引用。那么就直接
domain.method2(this,parameters);

域对象只接收参数的service,而客户端不直接调用domain增加隔离性即可。
38 楼 czx566 2009-01-09  
如果你考虑用工厂的对象来new 领域模型的话

事务依然是可 配置的~
37 楼 nfxu 2009-01-09  
连接管理?没有啊,顶多是事务边界需要手工指定啊:

Session session = sessionFactory.getCurrentSession();
try {
session.beginTransaction();
businessList = session.createQuery("from Business").list();
session.getTransaction().commit();
} catch (Exception e) {
session.getTransaction().rollback();
    throw e;
}
36 楼 tiyi 2009-01-09  
折腾啊。。。还要承担连接管理啊什么的成本。
35 楼 nfxu 2009-01-08  
charles_zuo 写道
我觉得你可以去看看《领域驱动设计》这本书,它定义的领域模型要素里面,其实将一个Domain Object分成了Domain 和 Repository,Domain 处理业务逻辑,不和持久层相关,Repository处理CRUD等持久层相关的操作。而Service是处理需要多个Domain协同操作的业务。整个模型中,只有Repository和底层的持久层相关。由于Java语言本身的特性,不能想Rails中那样将Domain和Repository合并成一个对象。



嘿嘿,我明白我是个半吊子,

你说的书我没读过,书太厚,很少读,不过我会在网上找找短一些的资料看看的,谢谢啦。
34 楼 charles_zuo 2009-01-08  
我觉得你可以去看看《领域驱动设计》这本书,它定义的领域模型要素里面,其实将一个Domain Object分成了Domain 和 Repository,Domain 处理业务逻辑,不和持久层相关,Repository处理CRUD等持久层相关的操作。而Service是处理需要多个Domain协同操作的业务。整个模型中,只有Repository和底层的持久层相关。由于Java语言本身的特性,不能想Rails中那样将Domain和Repository合并成一个对象。
33 楼 nfxu 2009-01-07  
DanielYWoo 写道
实施证明,充血模型是Martin大叔的失败的理论之一
JPA/EJB3要是用充血模型,甚至涨血模型,那就死定了
lz不要在域模型这上面费心思,域模型还是POJO最好用

再说了,其实持久化等功能本来从OO角度来看也不是域模型的职责
你这个架构实在是太别扭了

另外,IoC是有边界的,哪些bean需要从IoC获得,哪些需要new,哪些需要用factory/builder等pattern创建,这个要看具体架构需求。就域模型来说,new一下就可以了,除非你要spring cglib做aop


老实说,我个人用充血模型觉得挺好的。

领域Bean里有CRUD操作应该有一部分人这么用吧?如果是的,我就知足了。可能这个是不太好,但目前我还不想改变,可以理解为我没有能里做的更好。呵呵。
32 楼 nfxu 2009-01-07  
samm 写道
nfxu 写道
samm 写道
nfxu 写道
嗯。我说的往领域bean里注入session factory实际上是DAO,呵呵。

但是DAO同session factory一样,也是在application context里声明的,对他的引用只能是声明式的注入,无法在创建新领域bean的时候用代码显示的获得对DAO引用,这正是我面临的问题。

也可以这么说,如何在通过Web容器启动了application context后,在代码里取得对这个application context的引用?就像这样:
DomainBean myBean = applicationContext.getBean("domainBean");




千万不要在一个应用建两个context啊,是可以拿的,其实不过是application context是存在application里面的。

方式1
-----------spring 文档------------------

3.5.2.1.  BeanFactoryAware
对于实现了org.springframework.beans.factory.BeanFactoryAware接口的类,当它被BeanFactory创建后,它会拥有一个指向创建它的BeanFactory的引用。

----------^_^强大的分割线^_^--------------

方式2,但好很强大。
WebApplicationContext  wac = WebApplicationContextUtils.getWebApplicationContext(
servletConfig.getServletContext());

很简单,传个参数就可以了。如果觉得传参很麻烦,写个filter或servlet初始一个Util类就OK了(在spring初始化之后)

创建新领域bean,这个无从谈起,一个单例Bean不救OK了吗?

不过充血模型是不依赖持久层框架的,你所说的更象ALL-IN-ONE形式。




谢谢你的建议。方式一我看懂了,方式二不是很明白。但我不打算采用方式一,因为显得比较复杂,我目前可能处理的不会很好。我还是倾向于这样,用web.xml启动一个application context,用来注入struts的actions,再用Bean factory的方式启动一个Bean factory,用来往service里注入DAO,往DAO里注入session factory,而在领域Bean里从这个factory里得到DAO(就不是注入了)。

我这样做可能有风险,但目前项目规模很小,除了问题重构起来还是很快的,也算是学习的一个过程。你的方法我打算收藏了,万一我的笨办法有问题,再用你的。




这个是不是说你的应用里存在两个Bean factory呢?这个不好,事务控制可能无效,资源浪费!
方式2再说说。
说白了,application context无非是保存在application(请不要说这个不知道哦,jsp默认下提供的东东,filter 的init(FilterConfig arg0)方法中arg0.getServletContext()这样得到)中的变量。

这个变量是怎么来的呢? 请看下面的配置项。默认情况下,在这个listener中application.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,applicationcontext);

<listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>


WebApplicationContextUtils 这个是spring提供的工具类。


好,谢谢,我明白了。

我的数据库事务控制采用的是hibernate本身提供的,也就是这个样子:

Session session = sessionFactory.getCurrentSession();
try {
session.beginTransaction();
businessList = session.createQuery("from Business").list();
session.getTransaction().commit();
} catch (Exception e) {
session.getTransaction().rollback();
    throw e;
}


service层从整体上来说只是对上(Web/容器)提供服务,不应该依赖于Web,所以我的service里没有任何Web相关的API调用,只有标准的JSE类或其他的POJO类。所以我倾向于不从Web context里获取application context。
31 楼 nfxu 2009-01-07  
wangyugod 写道
nfxu 写道
情况是这样的:

1 一个架构为struts2,spring,hibernate的web应用。
2 采用充血的领域模型,即领域bean里含有一些简单的业务逻辑,例如CRUD之类的操作。这些操作需要hibernate的session factory以便访问数据库。
3 Spring中定义了session factory,因此可以将它注入任何需要的地方。同样也可以注入领域bean和service类中。

但问题是领域bean因为比较小(其实也不小,如果充血的话),一般用new的方式生成,因此无法从Spring中获得session factory。像service类比较大,一般是从Spring中获得实例,因此注入了session factory,没有问题。

如果是失血模型的话,领域类里只有getter 和setter方法,因此不存在注入session factory的问题。

当然我也可以用BeanFactory.getBean("beanName")的方式获得session factory,但这样就不够好看了,出现了applicationContext和BeanFactory并存的局面,感觉不优雅( 我现在的Spring是通过web.xml在Web服务器启动时载入的,因此是application context)。

难道大家不用充血模型?

在Spring reference的3.9. Glue code and the evil singleton中,似乎有些提示,但不怎么明白。


我认为CRUD这些操作不应该写在domain object里面,事实上CRUD也不属于domain logic范畴,只要在domain object中将状态修改好即可。实现上可以在application层进行事务提交控制(这些可以有AOP或Spring interceptor来做),一般来说这种是针对已持久化的对象的操作;对于新增的对象可以有Repository来完成。



我知道你说的这种情况。但你说的那些对我来说是在太高级了,我目前没有能力处理好。另外,从理论上说,我是不太愿意用太多的框架的,这产生太多的依赖。像这些AOP,Spring interceptor,听着很牛逼,可使得本来比较简单的结构变得复杂,产生过多的依赖,我是没有信心的。

1 struts,我用的就是actions,他的tag lib 我尽量不用,而是用标准的JSTL。其他我用Tiles和Validator。
2 spring,我就用IOC,其他的,白送都不要。
3 hibernate,我只用标准的sessionFactory.getCurrentSession(),和其中的transaction,使用代码声明事务。不用AOP等什么的。

为的什么,就是可维护性。关于在领域Bean里写CRUD,对我是最好的选择。我可以保证一个清晰,易于理解和维护扩展的系统。
30 楼 vipmail 2009-01-07  
aop注入很好很强大
29 楼 redeye 2009-01-07  
斑竹就是想问一下不用new 如何得到spring容器,你们说了4个分页到底在说什么呢。
28 楼 czx566 2009-01-07  
DanielYWoo 写道
实施证明,充血模型是Martin大叔的失败的理论之一
JPA/EJB3要是用充血模型,甚至涨血模型,那就死定了
lz不要在域模型这上面费心思,域模型还是POJO最好用

再说了,其实持久化等功能本来从OO角度来看也不是域模型的职责
你这个架构实在是太别扭了

另外,IoC是有边界的,哪些bean需要从IoC获得,哪些需要new,哪些需要用factory/builder等pattern创建,这个要看具体架构需求。就域模型来说,new一下就可以了,除非你要spring cglib做aop



很想听听 你上面所说的实施证明

因为对于领域模型 我接触的时间还是比较短,
不过当我接触到领域模型的理论了后,我还是认为这应该是一条光明大道

我现在做的项目我准备推行领域模型,至少是充血,甚至涨血也有可能。
因为我觉得随着java语言对动态语言的支持度的提高,涨血可能是最终的归途!
27 楼 redeye 2009-01-07  
所以可以直接在ServletContext取出WebApplicationContext 对象:

WebApplicationContext webApplicationContext = (WebApplicationContext) servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);

26 楼 jnoee 2009-01-07  
框架限制使你难于实现,可考察一下其它框架。
25 楼 DanielYWoo 2009-01-07  
实施证明,充血模型是Martin大叔的失败的理论之一
JPA/EJB3要是用充血模型,甚至涨血模型,那就死定了
lz不要在域模型这上面费心思,域模型还是POJO最好用

再说了,其实持久化等功能本来从OO角度来看也不是域模型的职责
你这个架构实在是太别扭了

另外,IoC是有边界的,哪些bean需要从IoC获得,哪些需要new,哪些需要用factory/builder等pattern创建,这个要看具体架构需求。就域模型来说,new一下就可以了,除非你要spring cglib做aop
24 楼 samm 2009-01-06  
nfxu 写道
samm 写道
nfxu 写道
嗯。我说的往领域bean里注入session factory实际上是DAO,呵呵。

但是DAO同session factory一样,也是在application context里声明的,对他的引用只能是声明式的注入,无法在创建新领域bean的时候用代码显示的获得对DAO引用,这正是我面临的问题。

也可以这么说,如何在通过Web容器启动了application context后,在代码里取得对这个application context的引用?就像这样:
DomainBean myBean = applicationContext.getBean("domainBean");




千万不要在一个应用建两个context啊,是可以拿的,其实不过是application context是存在application里面的。

方式1
-----------spring 文档------------------

3.5.2.1.  BeanFactoryAware
对于实现了org.springframework.beans.factory.BeanFactoryAware接口的类,当它被BeanFactory创建后,它会拥有一个指向创建它的BeanFactory的引用。

----------^_^强大的分割线^_^--------------

方式2,但好很强大。
WebApplicationContext  wac = WebApplicationContextUtils.getWebApplicationContext(
servletConfig.getServletContext());

很简单,传个参数就可以了。如果觉得传参很麻烦,写个filter或servlet初始一个Util类就OK了(在spring初始化之后)

创建新领域bean,这个无从谈起,一个单例Bean不救OK了吗?

不过充血模型是不依赖持久层框架的,你所说的更象ALL-IN-ONE形式。




谢谢你的建议。方式一我看懂了,方式二不是很明白。但我不打算采用方式一,因为显得比较复杂,我目前可能处理的不会很好。我还是倾向于这样,用web.xml启动一个application context,用来注入struts的actions,再用Bean factory的方式启动一个Bean factory,用来往service里注入DAO,往DAO里注入session factory,而在领域Bean里从这个factory里得到DAO(就不是注入了)。

我这样做可能有风险,但目前项目规模很小,除了问题重构起来还是很快的,也算是学习的一个过程。你的方法我打算收藏了,万一我的笨办法有问题,再用你的。




这个是不是说你的应用里存在两个Bean factory呢?这个不好,事务控制可能无效,资源浪费!
方式2再说说。
说白了,application context无非是保存在application(请不要说这个不知道哦,jsp默认下提供的东东,filter 的init(FilterConfig arg0)方法中arg0.getServletContext()这样得到)中的变量。

这个变量是怎么来的呢? 请看下面的配置项。默认情况下,在这个listener中application.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,applicationcontext);

<listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>


WebApplicationContextUtils 这个是spring提供的工具类。
23 楼 wangyugod 2009-01-06  
nfxu 写道
情况是这样的:

1 一个架构为struts2,spring,hibernate的web应用。
2 采用充血的领域模型,即领域bean里含有一些简单的业务逻辑,例如CRUD之类的操作。这些操作需要hibernate的session factory以便访问数据库。
3 Spring中定义了session factory,因此可以将它注入任何需要的地方。同样也可以注入领域bean和service类中。

但问题是领域bean因为比较小(其实也不小,如果充血的话),一般用new的方式生成,因此无法从Spring中获得session factory。像service类比较大,一般是从Spring中获得实例,因此注入了session factory,没有问题。

如果是失血模型的话,领域类里只有getter 和setter方法,因此不存在注入session factory的问题。

当然我也可以用BeanFactory.getBean("beanName")的方式获得session factory,但这样就不够好看了,出现了applicationContext和BeanFactory并存的局面,感觉不优雅( 我现在的Spring是通过web.xml在Web服务器启动时载入的,因此是application context)。

难道大家不用充血模型?

在Spring reference的3.9. Glue code and the evil singleton中,似乎有些提示,但不怎么明白。


我认为CRUD这些操作不应该写在domain object里面,事实上CRUD也不属于domain logic范畴,只要在domain object中将状态修改好即可。实现上可以在application层进行事务提交控制(这些可以有AOP或Spring interceptor来做),一般来说这种是针对已持久化的对象的操作;对于新增的对象可以有Repository来完成。
22 楼 czx566 2009-01-06  
lgx522 写道
这个所谓“贫血”、“充血”之论,大家其实没必要当真,扯来扯去,搞成经院式的空洞辩论了。
世间事本无“一招仙”的解决方法,如此在意“招式”是很无聊的。

国内搞Java和Spring的,大凡有点熟的,好像总喜欢扯点这类问题,好像挺有“深度”,其实是浪费时间精力。就算大家把MF的“模式”都搞清楚了,就真能解决一切问题了吗?不如学一学.NET、PHP和RoR,低头做点实事。Java世界不是用来折腾说事的,有能耐的,多写点有用的jar做开源才是要紧。


我的看法恰恰与你的相反~
我认为中国的软件界就是跟风太快~
功利心太强。
什么都搞,什么都不精通
最后永远只能跟着老外的屁股后面~
说白了,好像什么都会,但实际问得深入一点,反而就茫然了。




21 楼 nfxu 2009-01-06  
samm 写道
nfxu 写道
嗯。我说的往领域bean里注入session factory实际上是DAO,呵呵。

但是DAO同session factory一样,也是在application context里声明的,对他的引用只能是声明式的注入,无法在创建新领域bean的时候用代码显示的获得对DAO引用,这正是我面临的问题。

也可以这么说,如何在通过Web容器启动了application context后,在代码里取得对这个application context的引用?就像这样:
DomainBean myBean = applicationContext.getBean("domainBean");




千万不要在一个应用建两个context啊,是可以拿的,其实不过是application context是存在application里面的。

方式1
-----------spring 文档------------------

3.5.2.1.  BeanFactoryAware
对于实现了org.springframework.beans.factory.BeanFactoryAware接口的类,当它被BeanFactory创建后,它会拥有一个指向创建它的BeanFactory的引用。

----------^_^强大的分割线^_^--------------

方式2,但好很强大。
WebApplicationContext  wac = WebApplicationContextUtils.getWebApplicationContext(
servletConfig.getServletContext());

很简单,传个参数就可以了。如果觉得传参很麻烦,写个filter或servlet初始一个Util类就OK了(在spring初始化之后)

创建新领域bean,这个无从谈起,一个单例Bean不救OK了吗?

不过充血模型是不依赖持久层框架的,你所说的更象ALL-IN-ONE形式。




谢谢你的建议。方式一我看懂了,方式二不是很明白。但我不打算采用方式一,因为显得比较复杂,我目前可能处理的不会很好。我还是倾向于这样,用web.xml启动一个application context,用来注入struts的actions,再用Bean factory的方式启动一个Bean factory,用来往service里注入DAO,往DAO里注入session factory,而在领域Bean里从这个factory里得到DAO(就不是注入了)。

我这样做可能有风险,但目前项目规模很小,除了问题重构起来还是很快的,也算是学习的一个过程。你的方法我打算收藏了,万一我的笨办法有问题,再用你的。

相关推荐

    充血模型设想实现(2010/07/30更新)

    综上所述,"充血模型设想实现"这一主题涵盖了软件设计的核心思想,即如何通过领域模型来表达和实现业务逻辑。在2010年的讨论中,可能深入探讨了如何利用充血模型提升代码质量、可维护性以及业务逻辑的一致性。结合...

    失血贫血充血胀血模型.docx

    1. 学习曲线:理解和实现充血模型可能需要对领域建模有较深的理解。 2. 测试复杂性:由于领域对象包含了复杂的业务逻辑,测试可能更为复杂。 【胀血模型】 胀血模型是对充血模型的一种扩展,领域对象不仅包含业务...

    基于六边形架构的充血领域模型设计源码——Freedom框架

    该项目为Freedom框架,是一款基于六边形架构的充血领域模型设计源码,采用Go语言开发,总计包含200个文件。文件类型涵盖了178个Go源文件、6个Markdown文档、4个TOML配置、4个YAML配置、2个SQL脚本、1个Git忽略规则、...

    基于GO的六边形架构框架,可支撑充血的领域模型范式代码实现.rar

    本资料主要关注的是使用Go语言实现的一个六边形架构框架,它特别适用于支持充血的领域模型范式。让我们深入探讨这些概念以及它们如何相互关联。 首先,我们来了解什么是六边形架构,也被称为端口和适配器架构。这种...

    对贫血和充血模型的理解

    贫血模型和充血模型是两种在软件开发,尤其是面向对象编程中常见的设计策略,主要应用于领域驱动设计(Domain-Driven Design, DDD)中。这两种模型主要关注于业务逻辑和数据之间的关系,以及如何在软件架构中有效地...

    领域模型说明及范例代码.zip

    在软件开发领域,模型设计是核心部分之一,它有助于我们理解和表述复杂的业务逻辑。领域模型(Domain Model)和贫血模型(Anemic Domain Model)是两种常见的模型设计模式,它们各有特点,适用于不同的场景。本资料...

    领域模型驱动设计1553265830.pdf

    领域模型分为贫血模型和充血模型两种。 - 贫血模型指的是领域对象只包含了数据访问方法(get和set方法)和一些简单的CRUD(创建、读取、更新、删除)方法,而所有的业务逻辑都放在了BusinessLogic层。 - 充血模型则...

    领域驱动(DDD)充血模式下,domain 与 Service以及Repository的解耦---DOMAIN EVENT

    领域模型是业务逻辑的抽象表示,它包含了业务领域的实体(Entities)、值对象(Value Objects)、领域服务(Domain Services)和仓储(Repositories)等元素。在充血模式下,这些组件拥有丰富的业务逻辑,而不仅仅是...

    浅谈Asp.net中使用“充血模型”1

    在Asp.net开发中,"充血模型"是一种提倡领域对象拥有丰富行为和业务逻辑的设计模式,相对应于传统的"贫血模型"。"贫血模型"通常将数据模型、业务逻辑和数据访问分离,使得领域对象仅包含属性,而业务逻辑和数据操作...

    领域驱动设计案例-盒马实践

    领域模型可以分为失血模型、贫血模型和充血模型三种类型。 失血模型 失血模型是基于数据库的领域设计方式,它指的是使用 POJO 数据对象来存储业务数据。在失血模型中,业务逻辑是分散的,分布在多个地方。 贫血...

    领域驱动设计学习总结(一)

    2. **限界上下文(Bounded Context)**:限界上下文是DDD中的一个重要概念,它定义了领域模型的边界,明确了模型在特定业务领域的适用范围和语义。 3. **领域统一语言(Ubiquitous Language)**:领域统一语言是...

    大白话领域驱动设计DDD视频教程

    第2章 领域分析模型 核心域,支撑子域,通用子域 微服务和DDD是什么关系? 传统模式下如何合理的划分各种域 基于DDD的方式进行域划分 什么是通用语言 什么是限界上下文? 限界上下文和子域的关系 基于电商系统按流程...

    DDD领域驱动设计day01.pdf

    领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,由Eric Evans在其同名著作中提出,旨在帮助开发者更好地理解和处理复杂的业务逻辑,通过深入挖掘领域知识来构建高质量的软件系统。DDD的核心是...

    论文研究 - 雅温得大学教学医院重症监护室充血性心力衰竭的模式和结果:跨领域研究

    背景:在我们所在的重症监护病房中,充血性心力衰竭(CHF)的数据很少。 这项研究旨在为雅温得大学教学医院的重症监护病房提供更好的CHF模式和预后知识。 方法:我们进行了为期21个月的描述性和回顾性研究。 我们从...

    领域驱动设计

    4. **限界上下文**:为了管理复杂度,DDD引入了限界上下文(Bounded Context)的概念,每个限界上下文定义了一组相关的领域模型和业务规则,它们之间通过接口和服务进行通信。 5. **事件溯源(Event Sourcing)**:这是...

    11丨实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?1

    2. 领域驱动设计:在需要紧密贴合业务领域模型的项目中,充血模型能够更好地体现业务实体及其行为。 3. 提升代码质量:追求更高质量的代码,减少不必要的转换和重复代码,提高整体系统的稳定性。 总的来说,选择...

    tbl-demo-service-master.zip

    那么领域模型的作用微乎其微,甚至可以忽略,数据转换的成本比领域模型带来的好处还多,这种情况其实就是在原有的分层架构中多加了一层,增加了项目的复杂性和工作量。 “领域驱动开发DDD”只有被正确地运用,才能...

    DDD领域驱动设计初探(6):领域服务 - 文章 - 伯乐在线1

    然而,遵循DDD的原则,我们应尽可能使领域模型丰满,保持“充血模型”,即将所有领域逻辑保留在领域层。因此,处理实体间关系的逻辑更适合放在领域服务中。 以权限管理为例,假设我们需要实现一个功能,将指定用户...

    自由:自由是一个基于六边形架构的框架,可以支撑充血的领域模型范式

    自由DDD框架自由是一个基于六边形架构的框架,可以支撑充血的领域模型范式。总览集成虹膜HTTP / H2C服务器和客户端集成普罗米修斯AOP工作者和无侵入上下文可扩展组件依赖注入&依赖倒置&开闭原则DDD和六边形架构...

Global site tag (gtag.js) - Google Analytics