This version can hold you over in the meantime: http://www.infoq.com/minibooks/domain-driven-design-quickly

The e-book is a summarized version of the Evans book.

I’m on my third reading of the Evans book and as Joe said, I’m always learning something new as well (although I’m way behind Joe’s level of understanding).

the only thing that stinks is amazon says it will be 3 weeks before they can ship it out =(

oh well.

Nillson’s books is close but it only scratches the surface of what you are about to learn.

Good luck.

I ordered Eric Evans book yesterday on Amazon. I couldn’t hold back any longer =)

Now I finally have a chance to go back and do some quality refactorings on this kind of stuff, hence the namespaces and also elimited unnecessary interfaces. IPost is definately a good candidate =)

the funny part is it doesn’t have many responsibilites at all. i think i smell something =)

I’d be suspicious of why you couldn’t just construct your scenario using real objects, so IPost just seems to stand out as weird to me. Maybe a sign that it has too much responsibility, I don’t know.

I see what you mean. You aren’t just blindly creating interfaces for all your domain classes just for the sake of having interfaces.

IUser I mock quite a bit in the tests, in addition to exposing the interface to my controllers assembly. IComment is a bad example because I actually no longer am using that.

IPost was made to mock posts attached to users and websites.

All in all, not that many entities implement interfaces. Once a couple of them got quite complex I refactored to interfaces to minimize coupling, seemed to work alright for the time being.

I’ve never seen a need to mock these, so I’m wondering what value you’re getting out of them.

Don’t apologize, I took me 2 years, rereading Evan’s book 3 times making lots of mistakes before I really felt comfortable discussing it with other people.

>In other words, the namespace organization shouldn’t define boundaries or do you mean something different?

The exact opposite, they should define “Context Boundaries”. Evan’s refers to this as “Bounded Context” [Evans pg. 335] and may be overkill for most projects but I like to still discuss them because that are the natural evolution of “Modules” [Evans pg. 109].

Modules offer low coupling between context boundaries and high cohesion within.

If you think of let say an eCommerce system and you are building an enterprise system I can think of several modules off the top of my head

MyCompany.eCom.Warehouse.InventoryMangement
MyCompany.eCom.Warehouse.VendorManagement
MyCompany.eCom.Store.OrderManagement
MyCompany.eCom.Store.CustomerManagment
MyComapny.eCom.Store.SecurityMagnement
etc.

As you can see each module has a context that is specific to it’s operation and function within the company. Could each of these be thier own assembly? (Drum role) It depends, on a large scale enterprise application there can be multiple development teams working on each bounded context. Which would warrant multiple assemblies being developed. If there isn’t multiple development teams then best judgment should be utilized. If one of the context boundaries begin to grow out of control consider moving it to its own assembly and distill accordingly.

The way you would further insure that you adhered to low coupling between each context is utilize an Anti Corruption Layer between each context. [Evans pg. 364]

>…whether my authentication classes should live within my Controllers assembly or my core assembly.

OK this is where I get kind of Anal. LOL Stop thinking like a developer! Hard to do, trust me I know.

Let’s assume that you have a domain expert that you are working with in creating your application. It is important that you and the domain expert form a “ubiquitous language”. Is the “authentication” class an entity or a service? From a domain perspective does the product owner even understand what you mean by authentication service or is it a module that exist within the domain where within the authentication module there is a authenticationService that accepts a Credential value object and returns a User entity? ” The important concept here is agreement by both you and your domain expert on ALL of the domain concepts.

If you are the domain expert than put on your product owner hat and explain in English what the objects are called from a product owner perspective.

By far this is the most difficult part of teaching DDD to developers. They immediately starting thinking in design patterns.

To get a better understanding of what I mean read this post on my blog.

http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/02/a-discussion-on-domain-driven-design.aspx
http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/14/a-discussion-on-domain-driven-design-entities.aspx
http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/23/a-discussion-on-domain-driven-design-value-objects.aspx

Hope this helps.