建个私人网站怎么做,淘宝电商运营培训,网站模板受法律版权保护吗,网站建设 十年领域驱动设计之领域模型埃里克埃文斯#xff08;Eric Evans#xff09;已制定了域驱动设计#xff08;DDD#xff09;。 Martin Fowler是DDD的大力支持者和拥护者。 这些都是非凡的名字#xff0c;几乎可以肯定的是#xff0c;他们正在支持一些有价值的东西。 我不是在这… 领域驱动设计之领域模型 埃里克·埃文斯Eric Evans已制定了域驱动设计DDD。 Martin Fowler是DDD的大力支持者和拥护者。 这些都是非凡的名字几乎可以肯定的是他们正在支持一些有价值的东西。 我不是在这里争论。 也许我正在试图证明我编写软件的方式的合理性或者也许我只是试图清除事物并具有建设性。 让我们来看看。 什么是领域驱动设计的核心- 域 域模型 通用语言的抽象的概念。 我不会对此进行详细介绍–对于那些感兴趣的人有维基百科在页脚中有很多参考文献可供阅读。 从理论上讲这都是非常好的并且域驱动的构建软件的方式应该对所有人都有吸引力–毕竟构建该软件是为了该领域的利益而不是建筑师开发人员或QA的利益。 但是现在是实际部分–如何实施DDD 我将在当代的背景下回答这个问题即使用spring和hibernate之类的框架。 我会证明它们的用法合理。 Spring是一个非侵入性的依赖注入框架。 Fowler也强烈支持DI并且DI被认为是实现DDD的好方法。 Hibernate是使用关系数据库时使用对象的一种方法。 另一种方法是使用JDBC并手动构造对象但这很繁琐。 因此Hibernate不会影响体系结构部分-它是一种实用程序当然功能非常强大。 在本文中我将使用“Hibernate”和“弹簧”作为“给定的”尽管它们可以通过任何DI框架以及任何依赖对象的ORM或其他持久性机制进行更改。 用spring和hibernate实现DDD的公认方法是 使用Configurable使域对象有资格进行依赖注入它们不会在spring之前实例化因此它们需要这种特殊方法 在域对象中注入存储库对象以允许域对象执行与持久性相关的操作 使用薄的无状态的事务服务层外观来协调域对象 这篇广泛的文章中介绍了这种方法的实现和描述。 另一个示例没有Spring是http://dddsample.sourceforge.net/ 。 稍后再讨论。 这种方法的替代方法是贫血域模型 。 它被认为是一种反模式但同时非常普遍并且经常使用。 贫血数据模型的功能很简单–域对象内部没有业务逻辑–它们只是数据持有者。 而是将业务逻辑放在服务中。 之所以将其视为反模式是因为首先这似乎是一种程序方法。 它破坏了封装因为对象的内部状态完全不是内部状态。 其次由于领域对象是设计的中心因此如果它的操作不属于它而改为多个无状态服务类则很难更改它。 域驱动的设计针对中型到大型应用程序这些应用程序发生了很大变化并且需要一种简便的方法来快速进行更改而又不会破坏其他功能。 因此在对象本身内具有对象的所有功能非常重要。 这也可以确保减少重复代码。 因此代替让服务来计算价格 ProductServiceImpl.calculatePricecomplexProduct我们应该简单地拥有ComplexProduct.calculatePrice 。 因此每当领域专家说价格计算机制发生变化时更改的地方恰好是一种也是最直接的一种。 如果考虑简单的操作这看起来很容易。 但是当一个域对象需要另一个域对象来完成其工作时它将变得更加复杂。 使用贫血数据模型只需将另一个Service注入当前Service并调用其方法即可实现。 使用建议的DDD可以通过将域对象作为参数来实现。 在我看来域对象也是Hibernate实体已经设置了依赖项。 但不是在Spring之前因为Spring无法确切知道要注入哪个领域对象。 它们由Hibernate“注入”因为它确切知道应将哪个由主键标识域对象放置在另一个域对象中。 因此有一个奇怪的例子–如果产品腐烂并且必须在仓库中分配气味则必须调用例如Warehouse.increaseSmellLevelgetSmellCoeficient 。 而且它有精确的仓库不受弹簧的干扰。 现在我不同意这一点。 大多数来源包括上面链接的两个来源都指出应将存储库/ DAO注入域对象中。 不他们不应该。 只需调用“保存”或“更新”就不需要了解对象的内部状态。 Hibernate仍然知道一切。 因此我们只是将整个对象传递到存储库。 让我们将其分为两个部分 业务逻辑和基础架构逻辑 。 域对象不应该了解基础结构。 那可能意味着它不应该知道它被保存在某个地方。 产品是否关心其存储方式 不这是“感兴趣”的存储机制。 这里是实际的缺点 CRUD通过简单地将存储库调用包装在所有域对象中来实现–代码重复 域对象可传递地依赖于持久性–即它不是纯域对象并且如果存储库发生更改则也必须对其进行更改。 从理论上讲仅当域规则和属性更改时才应更改 人们很容易将事务缓存和其他逻辑包含在域对象中 在上面的一篇文章中我将在此处为建议的解决方案打开一个括号以使代码重复和样板代码更易于处理。 建议生成代码。 而且我认为代码生成是一种罪过。 它将无法删除重复的或非常相似的代码并将其抽象化为工具。 最引人注目的示例是生成ProductDAOCategoryDAOWarehouseDAO等。生成的代码难以管理无法扩展且严重依赖于外部元数据这绝对不是面向对象的方法。 说到存储库在建议的示例中每个域对象都应该有一个存储库该存储库又将调用持久性机制。 那我们得到什么 用户在UI中按“保存”保存在服务上的UI调用以便获得事务支持保存在域对象上的服务调用保存在资源库上的域对象调用保存在持久性机制上的资源库调用持久性机制保存对象。 是我自己还是在这里调用域对象是多余的。 这是一种不增加任何内容的直通方法。 而且由于很多功能与CRUD相关是的即使在大型企业应用程序中也是如此这对我来说似乎很糟糕。 最后我发现Configurable方法是一个hack。 它在后台做了一些魔术这不是任何通用语言功能也不是设计模式并且为了了解它是如何发生的您需要大量的经验。 所以总结上面的大混乱 域对象不应由SpringIoC进行管理它们不应具有DAO或任何与基础结构相关的内容 域对象具有由Hibernate或持久性机制设置的它们依赖的域对象 域对象执行业务逻辑就像DDD的核心思想一样但这不包括数据库查询或CRUD –仅对对象内部状态进行的操作 几乎不需要DTO-在大多数情况下域对象都是DTO本身这节省了一些样板代码 服务执行CRUD操作发送电子邮件协调域对象基于多个域对象生成报告执行查询等。 服务应用程序层并不薄但不包括域对象固有的业务规则 应避免生成代码。 应该使用抽象设计模式和DI来克服代码生成的需求并最终–摆脱代码重复。 参考有关 领域驱动设计贫乏领域模型代码生成依赖项注入等的信息 请参见Bozho的技术博客上的JCG合作伙伴 Bozho。 相关文章 Spring和AspectJ的领域驱动设计 在域驱动设计中使用状态模式 ORM问题 什么是依赖倒置 是IoC吗 框架使开发人员愚蠢吗 每个程序员都应该知道的事情 JDK中的设计模式 Java最佳实践 翻译自: https://www.javacodegeeks.com/2011/09/on-domain-driven-design-anemic-domain.html领域驱动设计之领域模型
