Comments on: Domain-Driven Design: Sample Application http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/ Simple is better than complex. Complex is better than complicated. | @fedecarg Mon, 06 Feb 2012 14:38:53 +0000 hourly 1 http://wordpress.com/ By: Tom http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6866 Thu, 11 Nov 2010 14:23:10 +0000 http://blog.fedecarg.com/?p=1468#comment-6866 I was afraid of that answer, Im not a big fan of doctrine. The idea of using yaml, xml to make the mappings happen seems odd.

I would rather code the mappings. Also there is to much magic going on in doctrine. And it has some perfomance impact.

]]> By: lcf http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6865 Thu, 11 Nov 2010 10:03:41 +0000 http://blog.fedecarg.com/?p=1468#comment-6865 Hi Tom,
There’s just one decent solution at the moment. More or less universal. Doctrine 2.

Nothing else is even close.

]]> By: Federico http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6864 Thu, 11 Nov 2010 10:01:56 +0000 http://blog.fedecarg.com/?p=1468#comment-6864 Instead of wiring everything yourself, you can use a library like Doctrine.

]]> By: Tom http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6863 Thu, 11 Nov 2010 08:25:46 +0000 http://blog.fedecarg.com/?p=1468#comment-6863 Im wondering if anybody has a good solution to handle database relationships with Domain Driven Design. Im complety lost at the moment about how to handle them.

]]> By: lcf http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6770 Fri, 02 Jul 2010 12:40:31 +0000 http://blog.fedecarg.com/?p=1468#comment-6770 Let’s say I want another implementation of UserDAO, that would load users via http from a remote web service. I would have to convert all data that I load from that new data source into “rows” like if they were from flat db tables. This is not flexible at all. The logic of searching and loading data may vary from repository to repository, from data source to data source.

The thing you really need is an interface like UserRepositoryInterface that would always return domain objects, and you may rely on it in your services.

]]> By: Federico http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6769 Fri, 02 Jul 2010 12:23:05 +0000 http://blog.fedecarg.com/?p=1468#comment-6769 No. You need to separate a data resource’s client interface from its data access mechanisms.

]]> By: lcf http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6767 Wed, 30 Jun 2010 12:25:30 +0000 http://blog.fedecarg.com/?p=1468#comment-6767 UserDAO interface/implementation seems to be unnecessary.
It can’t be used without the repository and the repository can’t be used without some specific DAO implementation. What we need really is just
repository interface and implementation. Agree?

]]> By: Federico http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6754 Thu, 10 Jun 2010 09:54:52 +0000 http://blog.fedecarg.com/?p=1468#comment-6754 Implementing a Repository: http://bit.ly/ddd-repository

]]> By: Federico http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6751 Wed, 09 Jun 2010 13:54:41 +0000 http://blog.fedecarg.com/?p=1468#comment-6751 You are right. One Repository per Aggregate Root. In this case User is the Aggregate Root that controls access to the UserProfile.

]]> By: Jeboy http://blog.fedecarg.com/2009/03/22/domain-driven-design-sample-application/#comment-6750 Tue, 08 Jun 2010 00:51:34 +0000 http://blog.fedecarg.com/?p=1468#comment-6750 I think the persistence of UserProfile object is User object’s responsibility since it is member of its aggregates, an aggregate which is stored in the Repository. Meaning storing/saving the User aggregate is also taking care of persisting its related objects, though saving this aggregate in storage is lil’ bit tedious without an ORM but still it complies to the purpose and design of the Repository which is a collection of Aggregate Roots and abstracting Persistence layer from the Domain.

]]>