使用领域驱动设计的原则
我正在考虑实现一种领域驱动设计方法（类似于 此处），但希望将其与 Doctrine ORM 集成。有没有人成功地做过这样的事情？
我最初的本能是使用 Doctrine 作为 DAO 层，但 Doctrine 映射我的数据库字段似乎有点复杂，而我的实体对象映射到（本质上）Doctrine 对象上的同一组字段。
我最初的目标是将所有 DQL/查询逻辑与我的域实体分离，但现在我在设计模式领域感到有点迷失。
我知道 Doctrine 2 应该为 DDD 技术提供一种更友好的方法，但我不确定我想等那么久。我想做的事情有意义吗，还是我应该寻找另一种方法？
谢谢。
I'm thinking of implementing a Domain Driven Design approach (similar to the one described here), but want to integrate it with the Doctrine ORM. Has anyone had any success doing anything like this?
My initial instinct was to use Doctrine as the DAO layer, but it seems a a bit convoluted for Doctrine to map my database fields, and my entity objects map to (essentially) the same set of fields on the Doctrine object.
My original goal was to separate all my DQL/query logic from my domain Entities, but now I'm feeling a little lost in design-pattern land at the moment.
I know Doctrine 2 is supposed to provide a much more friendly approach to DDD techniques, but I'm not sure I want to wait that long. Does what I want to do make sense, or should I find another approach?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，Doctrine 对于 DDD 来说并不完美，因为缺少 Repository 类。 Doctrine 支持表数据网关和 Active Record 等模式，虽然这些模式对于某些问题来说是很好的模式，但不一定是“经典”DDD 的最佳选择。但是，您可以解决这些缺陷。
一种选择是从 Doctrine_Table 派生并将其用作穷人的存储库。例如，如果您有一个名为“BlogPost”的类，则可能有一个继承自 Doctrine_Table 的表类“BlogPostTable”。然后，您可以将“findByCategory”等方法添加到 BlogPostTable 类，使此类逻辑与域对象（继承自 Doctrine_Record）分开。它与“纯”DDD 所提倡的模式并不完全相同，但也足够接近了。
即使没有完全相同的设计模式，您仍然可以使用 DDD 的核心见解。主要的一个是通用语言，这一概念试图使用领域专家和开发人员都可以阅读的精确语言来描述您的领域。
Doctrine is, in my opinion, imperfect for DDD because of the lack of a Repository class. Doctrine supports patterns such as Table Data Gateway and Active Record which, whilst good patterns for certain problems, aren't necessarily the best choice for 'classic' DDD. You can, however, work around these deficiencies.
One option is to derive from Doctrine_Table and use that as a poor man's repository. For example, if you have a class called 'BlogPost', you might have a table class 'BlogPostTable', inheriting from Doctrine_Table. You can then add methods such as 'findByCategory' to the BlogPostTable class, keeping such logic separate from your domain objects (which inherit from Doctrine_Record). It's not exactly the same as the patterns advocated by 'pure' DDD, but it's close enough.
Even without the exact same design patterns, you can still use the central insights of DDD. The main one is the Ubiquitous Language, the concept of trying to describe your domain using precise language that is readable by domain experts and developers alike.