ThoughtShapes - Patterns - 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.

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.

The Monostate design pattern

Rjae Easton — Mon, 30 Apr 2007 10:37:26 -0400

The Monostate design pattern takes the general form:

public class ClassName
{
    private static int theStaticState = 0;

    public virtual int StaticState
    {
        get { return theStaticState; }
        set { theStaticState = value; }
    }
}

The type itself is not limited to a single instance but its state is. In this way the benefits of polymorphism are protected (no pun intended ;-).

I should add that there is

Rjae Easton — Mon, 30 Apr 2007 10:19:52 -0400

I should add that there is another way for a MarshalByRefObject to indicate infinite lifetime. Return null from InitializeLifetimeService as in:

public override object InitializeLifetimeService()
{
    return null;
}

Unless your object needs control over sponsor and renewal lifetime it is best to use this approach.

I'd like to point something

Steve Seymour — Fri, 27 Apr 2007 10:15:13 -0400

I'd like to point something out that might not be obvious to all readers. In Rjae's post you'll notice that he doesn't provide the code for the types he mentions (Message and MessageRepository) but instead provides the test fixtures that test these types. This is a very important, conscious (and I believe totally correct) decision he must have made and it emphasizes what we practice: The tests are the most important thing in the code. I say "must have made" in the previous sentence because I normally don't like making assumptions about another's thoughts, but I do know the way Rjae thinks in regards to this area and I also know his thoughts totally jibe with mine.

One perspective in particular to try to grab hold of is to look at the test fixture method names. When I read the test method names I gain an instant understanding of what the behavior of the CUT (Class Under Test) is. I therefore gain a much quicker understanding of the class than I would if I was looking at the actual code for the class. I'm not sure how obvious this is to readers, so I think it's worth mentioning. Even if you're only developing a class library for a client, it's a good idea to ship all the tests with the code. I know that if I hire someone to create a library for me I'd be giddy if they give me all the tests. (This is really not true, but only because I'd expect all the tests in advance--since that would be part of the contract with the library writer. If I didn't have such a contract, then I'd be giddy.)

And, as I've said before and will say again, this is why the tests serve as the documentation.

(No subject)

Steve Seymour — Wed, 14 Mar 2007 18:59:00 -0400

Hey, I should also say that we’re doing another session on TDD for our user group next Wednesday, if you happen to be in town. It’ll be on TDD and the GUI…should be fun…I think we have a lot of good content to share. Let me know if you can make it.

(No subject)

Steve Seymour — Wed, 14 Mar 2007 18:56:00 -0400

Hey, massybird.

I thought about it, and I also thought about using a static readonly NullTheoretical cached in the DomainObjectThatHasTheoreticalValue. I didn’t do it your way because I don’t want anyone setting the value to null. The best way would probably be to check to see if the value it is set to is null, and, if so, then set it to a cached static readonly instance of NullTheoretical. Agree? There was a bit of me that didn’t do it this way because I wanted to display the concept of not optimizing up front, but I would probably do it with the static readonly instance.

Are you Chief Architect/CEO/President/Superman over there yet?

(No subject)

massybird — Wed, 14 Mar 2007 16:44:00 -0400

Hey Steve,

Good illustration of polymorphism. Why not altogether get rid of IFs from your example, as follows:

public class DomainObjectThatHasTheoreticalValue
{
private ITheoretical itsTheoretical = new NullTheoretical( );

public virtual ITheoretical TheoreticalValue
{
get { return itsTheoretical; }
set { itsTheoretical = value ; }
}

Is there a chance that ThoreticalValue getter will never be accessed and you’re delaying object creation? But then again, as you said, NullTheoretical has small overhead. CU!