DDD & DDDLib在恒拓开源的发展历程与推广经验
2019-03-23 07:29:08 来源：沈阳软件公司 作者：沈阳软件开发
DDDLib的焦点实现如下：
上图就是使用 DDDLib 项目的整体手艺架构图，也讲明了DDDLib的整体原则：
- 领域层是营业焦点，这一层不依赖任何特定的手艺框架，保证它的营业贞洁性。DDDLib中的领域层只依赖JDK、DDDLib的Domain库以及仓储接口及其它自界说接口。使用仓储和查询通道作为与存储介质相关的操作接口，隔离对特定数据库手艺或存储介质的依赖。提供多种差别的IoC容器实现及InstanceFactory实例工厂，隔离对特定IOC 手艺的依赖。领域层包罗值工具、领域工具以及领域服务三个要素，领域层不是数据库操作层而是营业建模层。许多开发者在使用的历程中，最终照旧把领域层作为数据库操作层来使用，对实体的要领也是以数据库的操作行为为尺度 ，如查询，新增，删除一个实体，最终依然回归到以数据库为中央的偏向去了，这是需要制止的。改变以数据库为中央的焦点是意识到营业行为才是焦点，数据库存储是支持。意识到数据库是支持很是要害，营业上的任何行为，在系统中最终需要存储记载，数据库存储是对营业实现的支持，也可以使用文件，缓存或云空间等其它存储介质。想像一下，使用数据库举行设计的项目，最终就限制了存储介质为特定的数据库，若是下一次需要替换为云空间或缓存等其它存储形式，就会发现整个系统需要重新设计开发，但使用DDDLib，只需替换仓储实现，提供一个云空间的实现就行了，焦点营业逻辑完全不需要变更与修改。
DDDLib在实现历程中也履历了内部的不少争议，经由许多次的讨论和打磨形成了现在的格式。在下面的部门，我将先容DDDLib在几个主要组件上的实现细节。
DDDLib仓储的实现
从DDDLib 1.0到3.5版本，仓储实现历经几个阶段，划分是：
- 给每个领域工具界说一个仓储接口及一个仓储实现。
这种仓储实现很是受争议，开发职员并不认可这种方式，仓储接口及实现很是多，一方面导致项目类太多，而且也带来编码的重复操作。
与spring data整合，给每个领域工具界说仓储接口，无须界说实现。这种模式对前面的模式有了优化，只界说接口不界说实现，可是spring data这种依赖要领名，参数来举行查询的模式，针对一些庞大的查询，难以胜任。提供默认的hibernate及JPA的通用仓储接口。为每个仓储界说一个接口，这种模式逐步的不被接受，使用spring data带来的优化方案，也有很是多的问题，后面凭据JPA的实体治理思绪，于是形成了通用仓储接口及差别手艺实现的思绪，界说一个通用的仓储接口，包罗通用的增删改查数据库行为。
支持MyBatis的通用仓储接口DDDLib的JPA及hibernate仓储实现，这个方案是一个较佳的方案，所有领域实体使用通用的仓储，制止了大量重复代码，但DDDLib一直是基于Hibernate/JPA提供的实现与手艺支持，在项目的使用历程中，经常会遇到不适合使用Hibernate/JPA模式的项目，对MyBatis的需求也很是大，这种情形下，Koala团队界说实现了MyBatis的仓储实现，并保证其与JPA/Hibernate模式下API的一致性。
DDDLib中的DTO
DTO，数据传输工具，领域工具虽然有数据（属性），可是领域工具上面还带有操作，在某些场所不适合举行传输，有些时间传输还需要序列化。但并不是所有的领域工具属性都可以袒露，而且有些属性可能要合并，可能要剖析，之后才有利于前端的使用。于是就有了专门用来传输数据的DTO，只有属性，没有操作，须要的时间加上序列化标志，实现远程挪用。
这是DDD中DTO的作用，可是DTO同时也带来了实体与DTO的转换性能问题，在大数据量下尤其显着。
DDDLib中的数据库支持行为类
在DDDLib实现中，提供了Repository以及QueryChannelService两个接口，划分使用在领域层以及应用层，都是对数据库的操作接口。
SQL/HQL/JPQL写在哪
在使用DDDLib的历程中，差别的持久层框架的SQL语言纷歧样，好比MyBatis使用的是SQL，Hibernate使用的是 HQL，JPA下使用的是JPQL。
这些语句写在哪儿在公司也履历过一番争议与变换，历史如下：
1、写在代码中
public static
“沈阳软件公司”的新闻页面文章、图片、音频、视频等稿件均为自媒体人、第三方机构发布或转载。如稿件涉及版权等问题，请与
我们联系删除或处理，客服QQ:55506560，稿件内容仅为传递更多信息之目的，不代表本网观点，亦不代表本网站赞同
其观点或证实其内容的真实性。
热门文章
使用“扫一扫”即可将网页分享至朋友圈。
