myController.Photos = photoSet.UsingOnly(Color.Red);

public IEnumerable List()
{
return myController.Photos;
}

public void Apply(string text)
{
return myController.Photos.MarkWithMetadata(text);
}

Granted, this is a too simplistic example as always with DDD. But you can see that as this gets more complex I’d have to pass around references to repository and services and/or specifications (Color.Red).

In this case “PhotoSet” is a domain specific term which is why I went with that. Even though Set is also a technical term I favored the ubiquitous language. I’ve also had the terms Collection and List in my domains. Imagine a fashion designer’s “collection” or a customer “list” with own domain properties.

It’s not my place to dictate the UL of the domain. ]]> http://blog.calyptus.eu/seb/2009/05/transitory_domain_object/comment-page-1/#comment-21 Roger Alsing Sun, 31 May 2009 08:09:08 +0000 http://blog.calyptus.eu/?p=125#comment-21 IMO, what you are doing is Domain Services with an Internal DSL API. I do like the look of that API. But it would be possible to make it as a pure old domain service too: var photoService = new PhotoService(); photoService.MarkWithMetadata( photoRepository , colorDetectorService, metaDataService, Color.Red, "RED"); Or if you use a container of some sort to configure your service instances. var photoService = foo.Get(); photoService.MarkWithMetadata( Color.Red, "RED"); But I do like the fluent interface / internal DSL approach you have. The thing that bothers me about it though is that "PhotoSet" is probably ambigious semantics with what you get from a photo repository. You do get sets of photos from photo repositories. (most likely some IList (ignoring the fact that ilist is not a true set interface)) Thus it would blur the meaning of a "photo set" Unless you explicitly starts talking about Photo Sets and Collections of Photos. IMO, what you are doing is Domain Services with an Internal DSL API.

I do like the look of that API.
But it would be possible to make it as a pure old domain service too:

var photoService = new PhotoService();
photoService.MarkWithMetadata( photoRepository , colorDetectorService, metaDataService, Color.Red, “RED”);

Or if you use a container of some sort to configure your service instances.

var photoService = foo.Get();
photoService.MarkWithMetadata( Color.Red, “RED”);

But I do like the fluent interface / internal DSL approach you have.
The thing that bothers me about it though is that “PhotoSet” is probably ambigious semantics with what you get from a photo repository.

You do get sets of photos from photo repositories.
(most likely some IList (ignoring the fact that ilist is not a true set interface))

Thus it would blur the meaning of a “photo set”
Unless you explicitly starts talking about Photo Sets and Collections of Photos.

Yea, what I meant to say was that it isn’t a persistent concern within the domain. Even if that persistence is only in memory. A property of an entity is persistent as opposed to a temporary variable in a method. (Suggestions for better verbiage are welcome.)

Service references are a transient concern during a certain operation only. I.e. infrastructure.

Yea, this is typically using double dispatch.

>> That is not completely true, “domain services” are apart of the domain itself, and have a very clear role in the domain.

Services is such an overused term and it’s unclear when to use it. Services in DDD are too undefined and can span various concepts. Thus violating single responsibility.

“Domain services” is close to what I’m doing but I’m using a slightly definition and different constraints to put it more in line with the UL and ensure separation of concerns.

I don’t couple any external operations to my transient domain objects. They are side-effect free, as Haskell people would call it. Therefore I don’t use an interface and I don’t bother with IoC because they contain only side-effect free domain logic.

>>The reference itself is (usually) infrastructure and not really a persistence concern.

Entities are not supposed to deal with persistence concerns, they are supposed to deal with _domain_ concerns.
The entire point of POCO is not have persistence concerns in the entities.

I do agree that keeping service references are an infrastructure concern, and should if possible be abstracted away.
In the easiest case it can be done by simply require the consumer to pass the reference into a method instead.
e.g. order.CalculateTotals(_someTaxCalculatorService_);

There are also other means to reach separation of concerns, eg AOP or introducing transient entities that operate over other entitie as you describe here.

>> Moving domain logic to services is a big no, no. That’s a gateway to anemic domain models

That is not completely true, “domain services” are apart of the domain itself, and have a very clear role in the domain.
They keep functionallity that does not fit into an entity (persistent or transient) by the simple fact that it is an operation that is not associated with any sort of identity (persistent id or transient pointer/ref)
but is rather operating over a set of different entities.

I do however agree that moving functionallity that does belong in an entity is a big no no.