Comments on: Factory and Repository in the Domain http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/ // TODO: think of a witty and intelligent tagline Thu, 18 Mar 2010 05:32:16 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Lyronne Rangan http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-781 Lyronne Rangan Wed, 31 Dec 2008 12:37:21 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-781 As far as I understand, you would define one repository per aggregate root and defining the aggregate boundaries in a model will cause a dramatic reduction in the amount of repositories rather than an over complication. I don't see how datamapper and repository are mutually exclusive choices. A repository is supposed to behave like an in memory collection of objects, those objects being aggregates. The repository need only expose queries to the aggregates and we navigate down the graph from the root. This view promotes the enriching of the model because it forces you to use the relationships, or a query object to retrieve chidren of interest from the aggregate root. A datamapper typically deals with a class or family of classes. In the case of value objects perhaps used in more than one aggregate, it would have it's own datamapper. It can... if you enforce the unidirectional relationship (which evans promotes) between the value object and it's parent because a bi-directional one may not make sense. So you could use the same datamapper in more than one repository. Here I see the repository as the lasting concept and the datamapper as a transient one. Even through I use datamapper my UnitOfWork only knows about an IPersistence interface when we are ready to commit object changes. As far as I understand, you would define one repository per aggregate root and defining the aggregate boundaries in a model will cause a dramatic reduction in the amount of repositories rather than an over complication. I don’t see how datamapper and repository are mutually exclusive choices. A repository is supposed to behave like an in memory collection of objects, those objects being aggregates. The repository need only expose queries to the aggregates and we navigate down the graph from the root. This view promotes the enriching of the model because it forces you to use the relationships, or a query object to retrieve chidren of interest from the aggregate root. A datamapper typically deals with a class or family of classes. In the case of value objects perhaps used in more than one aggregate, it would have it’s own datamapper. It can… if you enforce the unidirectional relationship (which evans promotes) between the value object and it’s parent because a bi-directional one may not make sense. So you could use the same datamapper in more than one repository. Here I see the repository as the lasting concept and the datamapper as a transient one. Even through I use datamapper my UnitOfWork only knows about an IPersistence interface when we are ready to commit object changes.

]]> By: Daniel Fernandes http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-779 Daniel Fernandes Wed, 24 Dec 2008 00:26:30 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-779 A year ago on my first attempt to do DDD (the idea sounded good and strangely simple) I did the mistake of creating too many packages and was afraid of giving access to Repositories from the Domain Model. I think there is indeed a lot of misunderstanding in that some people understand Domain Model as being "the" Domain. In simplifying DDD by doing so we can only end up with a more anemic model that one might expect. My guess is that asynchronous operations should be dealt in a diffeerent maner, probably by using Domain messaging which is simple in itself to implement. Daniel Fernandes A year ago on my first attempt to do DDD (the idea sounded good and strangely simple) I did the mistake of creating too many packages and was afraid of giving access to Repositories from the Domain Model.
I think there is indeed a lot of misunderstanding in that some people understand Domain Model as being “the” Domain.
In simplifying DDD by doing so we can only end up with a more anemic model that one might expect.
My guess is that asynchronous operations should be dealt in a diffeerent maner, probably by using Domain messaging which is simple in itself to implement.

Daniel Fernandes

]]> By: Martin Payer http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-778 Martin Payer Fri, 12 Dec 2008 21:10:21 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-778 Who says that ojbects of domain layer aren't allowed to hold references on DAOs? In every layered architecture I've seen DAOs were in the infrastructure layer. Domain objects are in domain layer. Infrastructure layer is below domain layer. In Eric Evans DDD there is even an example where an association between two model objects is expressed by a getCollection() method that executes a query directly. Who says that ojbects of domain layer aren’t allowed to hold references on DAOs? In every layered architecture I’ve seen DAOs were in the infrastructure layer. Domain objects are in domain layer. Infrastructure layer is below domain layer. In Eric Evans DDD there is even an example where an association between two model objects is expressed by a getCollection() method that executes a query directly.

]]> By: Ben Hutchison http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-748 Ben Hutchison Tue, 25 Mar 2008 03:00:21 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-748 Yes, Yes, Yes. We need this said more often. Its good to see the tide turning against the flawed idea that you can have a domain model thats both behaviorally rich and yet never initiates interaction with the world around it. Other than domain -> repository access, the other archetypal case of useful domain -> service access are services that listen to domain events. Eg you might want to send an email to Prod Support when a BankAccount becomes illegally overdrawn. In my Spring/Hibernate-flavored enterprise world, support for injecting into domain objects is still a practical sticking point. My colleagues oppose the AOP-based weaving model provided by Spring 2.0 as too much "techno-magic". Yes, Yes, Yes. We need this said more often.

Its good to see the tide turning against the flawed idea that you can have a domain model thats both behaviorally rich and yet never initiates interaction with the world around it.

Other than domain -> repository access, the other archetypal case of useful domain -> service access are services that listen to domain events. Eg you might want to send an email to Prod Support when a BankAccount becomes illegally overdrawn.

In my Spring/Hibernate-flavored enterprise world, support for injecting into domain objects is still a practical sticking point. My colleagues oppose the AOP-based weaving model provided by Spring 2.0 as too much “techno-magic”.

]]> By: Richard Pawson http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-703 Richard Pawson Fri, 07 Dec 2007 15:42:06 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-703 Glad to see someone denouncing the dominant design of putting all the business logic in the transaction scripts - get it back on the domain objects where it belongs. You say 'The transaction script (e.g. struts action in a web application if you’re so inclined) is simply responsible for finding an appropriate entry-point into the domain, then telling that domain class to do some work.' Are you aware of Naked Objects - we've taken this to the extreme, whereby you don't have any (developer-written) controllers at all. The framework provides you with direct access to the domain objects and their public methods. I think you'd love it. And to get you to the domain objects, we simply provide the user with direct access to (a subset of methods on) the Repositories, which we use in exactly the same way that you do. I'd be interested to hear your reactions to this idea. Richard Glad to see someone denouncing the dominant design of putting all the business logic in the transaction scripts - get it back on the domain objects where it belongs.

You say ‘The transaction script (e.g. struts action in a web application if you’re so inclined) is simply responsible for finding an appropriate entry-point into the domain, then telling that domain class to do some work.’

Are you aware of Naked Objects - we’ve taken this to the extreme, whereby you don’t have any (developer-written) controllers at all. The framework provides you with direct access to the domain objects and their public methods. I think you’d love it. And to get you to the domain objects, we simply provide the user with direct access to (a subset of methods on) the Repositories, which we use in exactly the same way that you do.

I’d be interested to hear your reactions to this idea.

Richard

]]> By: Chris http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-702 Chris Fri, 07 Dec 2007 06:53:40 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-702 Reminds me of this recent post by Philip Calcado: http://fragmental.tw/2007/11/29/repositories-misunderstandings/ Reminds me of this recent post by Philip Calcado: http://fragmental.tw/2007/11/29/repositories-misunderstandings/

]]> By: Ben Geyer http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/comment-page-1/#comment-701 Ben Geyer Fri, 07 Dec 2007 04:22:30 +0000 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/#comment-701 Great post. I strongly identify with your experiences and it gives me more to think about. Thanks! Great post. I strongly identify with your experiences and it gives me more to think about. Thanks!

]]>