ThoughtShapes - Design - Comments

Thank you for taking the

Anonymous — Mon, 19 Nov 2007 22:01:51 -0500

Thank you for taking the time to respond. Everything you said makes perfect sense, and it is nice to have this type of validation when coding DDD.

I believe passing the Repository to the constructor makes more sense because we should argue that the Customer does not have the “knowledge” to know which repository to create, and therefore it is logical for CustomerFactory to do this job (and it works better with unit tests). So I agree with all your point.

At this point, I am trying to use NHibrante to implement a prototype on this idea. When I am done, I will post it on my blog (http://mikeperetz.blogspot.com/) I would love your feedback on it.

Thanks for the complement on

Rob Scott — Mon, 19 Nov 2007 12:19:00 -0500

Thanks for the complement on the article.

You raise an interesting (and common) problem. If I were to implement lazy loading here to deal with the customer who had placed a million orders I would allow the Customer class to interact with an interface to an order repository (IOrderRepository). It would obtain an implemenation of that interface by calling a repository factory object to get the concrete implemenation and then use that to retrieve a smaller subset of the data. Using your example of a date range I would implement the customer get order method like so:

public class Customer
{
      IList GetOrders(DateTime from, DateTime to)
      {
           return RepositoryFactory.OrderRepository.GetOrders(this, from, to);
       }
}

Now since the Customer class is really referring to an IOrderRepository, I'd say that the Repository interface lives in the domain (with its client), and the concrete implementations live in their own namespaces (and probably assemblies).

Note that although I'm using a RepositoryFactory in this example, I might provide the indirection by just passing the IOrderRepository to the Customer when I created it. (This implies that whatever object created the Customer object would get the concrete implementation from the RepositoryFactory because we still want that run-time configurability.) I usually determine whether or not to pass the repository instances to the object on its constructor or have it use the RepositoryFactory directly based upon whether the object uses multiple repositories. If it uses one or two different repositories, I pass the instances, otherwise I just have the object use the RepositoryFactory to get the instances.

Does that make sense to you?

First of all, you wrote a

Anonymous — Sun, 18 Nov 2007 10:10:13 -0500

First of all, you wrote a very nice article. I think you are touching very fundamental issues. I am studying DDD now, and having trouble with a few scenarios.

Where do Repositories live? I feel that I am very limited if the repositories live within the Application layer only. I think lazy loading becomes a must in one point, because you don’t want to bring too much data from the database.

I also feel, that if you were to implement Specification pattern (Evens), then again you need the Repositories. Having said that, I think you should only use interfaces to them, and never use their true implementation.

When coding I sometime have a “the million rule”, what if there is a million orders to a customer. Or what if there are a million history records for a transaction. We should never bring that type of data down. We should probably use Query Pattern, which will work with Repositories.

Now I wonder, if I was to create a Customer and Order classes… does this makes snese?

List orders = customer.GetOrders(); // use Repository to implement this
Or
List order = customer.GetOrders(DateTime fromDate) // use Repository with Query pattern

What about adding an order?
customer.AddNewOrder(order);

Does code like that is DDD? If yes, the Repositories do live within the domain…

What is your take on this?
(Let’s assume that you can have a million orders per customer)

Office 2000/2003 version of

Rjae Easton — Sat, 03 Nov 2007 00:09:11 -0400

Office 2000/2003 version of documents have been attached to this posting.

Hi Robert! What you say

Jay — Fri, 02 Nov 2007 20:24:09 -0400

Hi Robert!

What you say makes a lot of sense, no surprise there, but I'm currently working on a project where the decision to use a particular database technology was made early on... pretty much at the beginning. Why? Well I don't want to use the wimpy excuse that "I wasn't working on the project at the time this decision was made", and even if I was I might not have been in position to directly work around this decision. Some of the decisions to select a database early were based on the following:

Our product is a website that we want to achieve scale on. And we wanted to be able to make performance measurements ASAP.
A database brings decades of doing certain things well. And we wanted to leverage that

Having said that, I also should tell you that: A) We are using Agile just as you describe and B) I >think< we used something akin to the repository concept in order to isolate the DB from other production code so that the other groups (we have multiple scrum teams running) wouldn't be blocked. I say Akin because we don't have a true in memory repository. We use NMock to "stub" out interfaces and inject test data.
With both of these statements, we are in a position (should we need to go in this direction) where we could change the DB, remove the DB etc, in a "safe": we have unit tests to catch dependencies but is anything truly 100% safe ;), and speedy (in a sprint) manner.

Having said all that, I do struggle (as I mentioned to Rjae) with the fact that we have what some people would consider business logic written into stored procedures, and I worry what the implications of changing the DB technologies would be underneath the interfaces we have.

So I have no problem with you saying "start with an in memory repository first." I truly feel that Agile and your 4th point "I’d make remaining neutral with respect to the piece of technology a design requirement and ensure that the development team knew to isolate that decision behind the appropriate interfaces" above are the ones that help us rule the day.

Great post! There is a TON of good material here. I'll come back to this post frequently.

Much of the material is

Rjae Easton — Fri, 26 Oct 2007 12:45:43 -0400

Much of the material is based on Robert C. Martin's Agile Software Development, Principles, Patterns, and Practices. There is also a new C#-only revision.