My service layer usually does messaging – those “special Message Objects” you alluded to (which are DTOs).

You might like this post describing how these two might work together in a broader perspective here:

Command Query Separation and SOA

The idea is not so much to do a “extract interface” refactoring, but rather to represent a use-case a concrete concept in code. Once that interface is there, we can do lots of useful things with it – for instance, different fetching strategies for different use cases.

I’d also like to refine my statements a bit and say that if there were two (or more) concrete classes that implemented the same interface (role), then, by definition, you shouldn’t care which class you get. If you think the code HAS to care, then you probably have a role struggling to express itself.

Does that make sense?

“One question that you might ask is what if there is more than one class that implements the same interface? How could the infrastructure know which class it should be loading? The answer is simple. You shouldn’t do that. Having two classes fulfilling the same role will get you in trouble even if you don’t use this design. The Single Responsibility Principle should be our guiding light.”

You are not really saying that SRP is driving you to define interfaces and then to only have one implementation?

This isn’t the way I read SRP at all, I read it as one reason for change. I also don’t see what you are suggesting as being the (only?) way to do interface based programming, in fact I’d argue its often silly to extract interfaces if you are 100% sure there will only ever be one implementation.

From the term role here I’m thinking of it being a role in the role-responsibility sense, if so I again would say that if multiple concrete classes can sensibly fulfill a role then a common interface is definitely the way to go?

Glad you like it.

Here’s what I think:

I do not duplicate the package diagram for each aggregate root. The packages called Interfaces, Infrastructure, and NHibernate are used by all.

I often find this pattern repeating (Service->Domain; Domain Objects->Domain; Persistence->Domain & Domain Objects) between bounded contexts.

I don’t often see the Customer class in a single bounded context. Rather, there is a different Customer class for each context, representing exactly the part it needs. When it comes to the “Customer Care” context, we see different rules around Orders, than in the “Online Shop” context.

I don’t quite view packages as units of reuse, but rather as a tool for managing dependencies.

Does that make sense?

we know that the Order type is an aggregate root, but we also know that the Customer type could also be an aggregate root (in another context)..

Do you duplicate your package diagram for each aggregate in your application/service? How does this packaging work with your Customer Service (where the context of the Customer aggregate includes other non-Order items)

This packaging scheme would seem ideal per aggregate (so that changing a table name is a single package change, adding a database column and new method would only affect 2 packages, etc)..but would end up with many dlls (which just means better change/configuration mgmt i suppose)..

I get the sneaky feeling you are going to tell me the Customer aggregate goes into a seperate service but figured i’d ask..

Given that packages are supposed to be units of reuse, how does that fit into your package schema (given that the Customer type crosses aggregate boundaries) if at all..