Comments on: Comments to Gavin King about DDD and Repositories http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/ better than writing good code is deleting code Sun, 07 Mar 2010 16:36:52 +0000 http://wordpress.com/ hourly 1 By: Fabio Kung http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-117 Fabio Kung Mon, 27 Oct 2008 15:19:17 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-117 @lonelybug Interesting use! @lonelybug

Interesting use!

]]> By: lonelybug http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-116 lonelybug Mon, 27 Oct 2008 05:21:56 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-116 i see what's you mean. here is one important advantage as you apply Repository rather than DAO. one more layer -- Repository, between Dao and Aggregate Entitry, which bring some flexiblity, for example, the cache or the concentration access point. for example if apply the Dao, then the client (caller) need to understand and learn some complicated detail or Dao objects. the codes should looks like: Client c=new Client(clientDao). if you do others, you also have to know the related Daos for those entities. but for Repository. the repository just apply for root entity for an aggregate. so there are more less repository need to learn or even you can apply repository factory pattern. codes looks like: Client c=new Client(RepositoryFactory.getInstance()) within the Client: Client(factory){ repository=factory.getRepository(Client.class); } hope can help you a little. i see what’s you mean. here is one important advantage as you apply Repository rather than DAO. one more layer — Repository, between Dao and Aggregate Entitry, which bring some flexiblity, for example, the cache or the concentration access point.

for example if apply the Dao, then the client (caller) need to understand and learn some complicated detail or Dao objects.

the codes should looks like:

Client c=new Client(clientDao).

if you do others, you also have to know the related Daos for those entities.

but for Repository.

the repository just apply for root entity for an aggregate.

so there are more less repository need to learn or even you can apply repository factory pattern.

codes looks like:

Client c=new Client(RepositoryFactory.getInstance())

within the Client:

Client(factory){
repository=factory.getRepository(Client.class);
}

hope can help you a little.

]]> By: Colin Jack http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-30 Colin Jack Sat, 24 Nov 2007 16:37:12 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-30 Is this just a variety on the Transaciton Script approach? Is this just a variety on the Transaciton Script approach?

]]> By: Stephan Schmidt http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-29 Stephan Schmidt Sat, 24 Nov 2007 13:43:59 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-29 @Dietmar: Wonderful! I've also implemented a large application with the business logic in commands and the data in objects. This was very useful and it was very easy to recombine and reuse commands for new business cases. I'll certainly take a look at tiny marbles. @Dietmar: Wonderful! I’ve also implemented a large application with the business logic in commands and the data in objects. This was very useful and it was very easy to recombine and reuse commands for new business cases. I’ll certainly take a look at tiny marbles.

]]> By: Dietmar Temps http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-28 Dietmar Temps Sat, 24 Nov 2007 13:03:02 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-28 @Stephan: It is interesting to read a comment like this. I'm a member of an Open Source project, called Tiny Marbles (http://www.tinymarbles.org). We are following a similar approach: we store objects in a repository. There are CRUD methods for the objects, that's almost all. The complete business logic we encapsulate using the Command pattern. I wouldn't say, that this approach would fit in every software project, but in a web application environment for business applications it is just wonderful. And it fits perfectly well to a RESTful architecture. The discussion here shows one thing very clearly: who says, the decision that 'getOrders' is connected to 'Client' is a good decision? Sometimes when starting the project the requirements are not known completely. At least while developing web application where requirements can change very often, it seems to me a better approach to maintain a stable domain model (which we do in our case in the Tiny Marbles repository), and delegate the business logic to 'services' (in our case using the Command pattern) which changes the state of the repository, or simply gives filtered information about the current state of the system. For the example you mentioned in your post we would prefer: getRepo.OrdersSinceDate(User, date). And we even go one step further: we are using the object 'User' with the role 'customer' or 'client'. @Fabio: I would love to discuss our philosophy with you, although I know, you don't agree and this place might not the right board for that. But hopefully some day there will be an opportunity :) @Stephan: It is interesting to read a comment like this. I’m a member of an Open Source project, called Tiny Marbles (http://www.tinymarbles.org). We are following a similar approach: we store objects in a repository. There are CRUD methods for the objects, that’s almost all. The complete business logic we encapsulate using the Command pattern. I wouldn’t say, that this approach would fit in every software project, but in a web application environment for business applications it is just wonderful. And it fits perfectly well to a RESTful architecture.

The discussion here shows one thing very clearly: who says, the decision that ‘getOrders’ is connected to ‘Client’ is a good decision? Sometimes when starting the project the requirements are not known completely. At least while developing web application where requirements can change very often, it seems to me a better approach to maintain a stable domain model (which we do in our case in the Tiny Marbles repository), and delegate the business logic to ’services’ (in our case using the Command pattern) which changes the state of the repository, or simply gives filtered information about the current state of the system. For the example you mentioned in your post we would prefer: getRepo.OrdersSinceDate(User, date). And we even go one step further: we are using the object ‘User’ with the role ‘customer’ or ‘client’.

@Fabio: I would love to discuss our philosophy with you, although I know, you don’t agree and this place might not the right board for that. But hopefully some day there will be an opportunity :)

]]> By: Stephan Schmidt http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-27 Stephan Schmidt Wed, 21 Nov 2007 05:13:31 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-27 @Fabio: No I'm not. After 20 years of developing applications with OO I think it's not the best way. From my experience FOOP is easier to refactor, easier to understand, easier to reuse and easier to maintain in the long run. Perhaps I have to blog an example to make people understand. Peace -stephan @Fabio: No I’m not. After 20 years of developing applications with OO I think it’s not the best way. From my experience FOOP is easier to refactor, easier to understand, easier to reuse and easier to maintain in the long run. Perhaps I have to blog an example to make people understand.

Peace
-stephan

]]> By: Fabio Kung http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-26 Fabio Kung Tue, 20 Nov 2007 23:15:12 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-26 @Stephan You are just kidding, right? @Stephan

You are just kidding, right?

]]> By: Stephan Schmidt http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-25 Stephan Schmidt Tue, 20 Nov 2007 18:39:24 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-25 "It feels too much procedural." In fact, after 20 years of OO I think OO is step in the wrong direction. Procedural is good. My programming style is FOOP. My methods aim to be functional, meaning they have no side effects and don't change state as much as possible. My objects just carry the data around and have some convenience methods for manipulating the data. All business logic is encapsulated in services, which are procedural and stateless. So my programming style is FOOP. Functional-OO-Procedural. Really, it's the future :-) Peace -stephan -- Stephan Schmidt :: stephan@reposita.org Reposita Open Source - Monitor your software development http://www.reposita.org Blog at http://stephan.reposita.org - No signal. No noise. “It feels too much procedural.”

In fact, after 20 years of OO I think OO is step in the wrong direction. Procedural is good. My programming style is FOOP. My methods aim to be functional, meaning they have no side effects and don’t change state as much as possible. My objects just carry the data around and have some convenience methods for manipulating the data. All business logic is encapsulated in services, which are procedural and stateless. So my programming style is FOOP. Functional-OO-Procedural.

Really, it’s the future :-)

Peace
-stephan

–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source – Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org – No signal. No noise.

]]> By: Colin Jack http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-24 Colin Jack Mon, 19 Nov 2007 14:05:31 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-24 To be honest I certainly don't think going to a repository is too procedural. I certainly don't want to make all the queries we use available on our aggregate roots, and why should I want to do it if the interface of the repository is part of the doman anyway? We don't need to hide the existence of repositories/services because they are a part of the model. To be honest I certainly don’t think going to a repository is too procedural. I certainly don’t want to make all the queries we use available on our aggregate roots, and why should I want to do it if the interface of the repository is part of the doman anyway?

We don’t need to hide the existence of repositories/services because they are a part of the model.

]]> By: Fabio Kung http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-23 Fabio Kung Mon, 19 Nov 2007 13:19:14 +0000 http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/#comment-23 <blockquote>A repository (or service which does some work and then calls the repository) seems like a better home.</blockquote> Sorry, but I disagree. <code>service.findOrders(client, date)</code> is <strong>exactly</strong> what I'm avoiding here. It feels too much procedural.

A repository (or service which does some work and then calls the repository) seems like a better home.

Sorry, but I disagree. service.findOrders(client, date) is exactly what I’m avoiding here. It feels too much procedural.

]]>