DDD & DDDLib在恒拓开源的发展历程与推广经验

　　领域驱动设计（DDD）的观点源于2004年著名建模专家Eric Evans揭晓的书籍:《Domain-Driven Design – Tackling Complexity in the Heart of Software》（中文译名：领域驱动设计—软件焦点庞大性应对之道），池建强在2011年揭晓的一篇文章《领域驱动设计和实践》中是这样形容DDD的：

领域驱动设计事实上是针对OOAD的一个扩展和延伸，DDD基于面向工具剖析与设计手艺，对手艺架构举行了分层计划，同时对每个类举行了计谋和类型的划分。

　　本文主要先容为什么我们在恒拓开源内部推广DDD，我们怎样通过开发 DDDLib 和 Koala 等工具来完善这一历程，推广历程中遇到了哪些问题，以及我们怎样解决这一问题。

　　为什么选择DDD

　　传统的模式的最大优点在于开发职员很是熟悉，开发成本低，但它也有一些问题：

　　接纳DDD开发模式之前，传统的开发模子是最盛行的Model-Dao-Service-UI开发模子，通常是基于事务剧本（Transaction Script）和表模块（Table Module）模式的实现，这种模式通常是先设计表，再建模，实现容易依赖特定的表的一些特征，如存储历程。基于表的设计模式容易带来以下几个问题：

营业建模完全是表的复制，无法真实反映营业。焦点营业疏散在各个地方，很是危险，修改扩展难，且难以阅读。

　　这种开发模式适合一些需求小，后续维护扩展需求小的中小型项目，但在大型企业级系统或产物，扩展维护或需求变量很是多的情形下，弱点也很是显着。

　　相对而言，DDD则有以下四点利益：

　　1、面向工具，模子真实反映营业现实：使用DDD领域驱动设计，模子通常是营业的真实反映，营业集中在领域而不是疏散在各Service中，有利于对营业的明白。

　　2、使用领域统一建模语言：有利于营业相同与建模： DDD提倡先对营业建模，而非关注表或剧本的设计；在建模历程中，由于领域自己是对真实营业的反映与建模，因此与营业专家更容易相同，打破手艺与营业的相同隔膜。

　　3、可重用性高：DDD中，领域层为焦点，每个领域工具都是一个相对完整的内聚的营业工具形貌，以是可以形成直接的复用。基于领域建模的设计，并不会依赖特定的数据库及特征，模子是可以完全重用且没有手艺上的冲突。

　　4、营业越庞大，DDD的优势越显着：领域模子接纳OO设计，通过将职责分配到响应的模子工具或Service，可以很好的组织营业逻辑，当营业变得庞大时，领域模子显出庞大的优势。

　　DDDLib登场

　　DDD本质上是一种头脑，并不是新手艺。在恒拓开源，由我们的杨宇先生和陈操总配合创作的DDDLib库，是对DDD头脑的焦点支持与实现。

　　DDDLib是一整套支持DDD头脑实现的类库，DDDLib下照旧使用的 Hibernate、JPA或MyBatis、noSQL等手艺为实现。

　　犹如DDD所要求样，使用DDDLib 的项目分层图为：

用户界面/展现层用于向用户展现信息，处置惩罚用户在界面上的请求，好比struts，tapestry，springMVC等页面框架。应用层用来处置惩罚应用的运动，不包罗领域中的营业逻辑。应用层可以用来处置惩罚一些与领域观点无关的阻挡性子的事情，好比日志，事务等。此外，应用层也可以用来处置惩罚一些既不属于展现层，也不属于领域层，而是属于现在应用相关的一些服务。好比资金转账的营业的读取输入功效（读取输入不是转账的焦点营业寄义）。领域层此层是DDD的焦点：领域工具，领域服务，仓储接口均位于此层。领域的信息，是营业软件的焦点所在。需要保留营业工具的状态，对营业工具及其状态持久化的操作交给基础设施层。领域层应该遵从以下原则：除非营业发生转变，否则其他任何转变均不应该影响到领域层。这些其他转变包罗：差别的展现框架，差别的页面展现内容，是否要分页，是否支持手机客户端，是否公然WebService，是否提供OpenAPI等等。基础设施层此层作为其他条理的支持，可以为领域层的持久化提供支持，当领域层或应用层有特殊的营业或应用需求(发送短信等)时，它们会界说需求接口，然后在基础设施层中实现这个接口，知足特定的营业或应用需求。

 1/5    1 2 3 4 5 下一页 尾页