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.