I have read this: https://stackoverflow.com/questions/25450380/can-value-objects-exist-without-entities, which says yes and this: http://enterprisecraftsmanship.com/2016/01/11/entity-vs-value-object-the-ultimate-list-of-differences/, which says no ("value objects cannot live by their own"). Therefore I have a simple example:

Option 1

public class DenominationsRequired
    public IEnumerable<System.Collections.Generic.KeyValuePair<decimal, int>> CalculateDenominations(decimal cost, ICurrency currency)


Option 2

I believe this is similar to the date type in .NET, which has methods that return a new date each time:

public sealed class DenominationsRequired
        private readonly decimal _cost;
        private readonly ICurrency _currency;

        public DenominationsRequired(decimal cost, ICurrency currency)
            _cost = cost;
            _currency = currency;

        public IEnumerable<System.Collections.Generic.KeyValuePair<decimal, int>> CalculateDenominations()


Option 1 returns the denominations required to meet a cost in a domain service and option 2 does the same thing as a value object. I have thought of the following criteria for choosing between a domain service and value object:

1) If the class is called once by an application service then a domain service is appropriate.

2) If the class is used by an entity or other value object then a value object is appropriate. Note that my first link above seems to contradict this.

3) An entity is not appropriate here because the object does not have identity and continuity. I guess I could create a GUID and make it an entity, however this seems like a bad idea.

I believe this should be a Domain Service based on my analysis. Have I understood this correctly? Are there any flaws in the criteria above?

  • 4
    You seem to be agonizing about this for quite a while. I still stand behind my previous answers and say that this is clearly a service. There is nothing that would make this piece of code a reasonable value object. – Euphoric Apr 9 '18 at 7:33
  • Does 1 exist, even if there is no entity that uses it? – Caleth Apr 9 '18 at 9:30
  • In complete agreement with @Euphoric here. Option 2 is not a value object. – David Arno Apr 9 '18 at 9:43
  • @Euphoric, thanks. I assume you are referring to the comment I added to your other answer over the weekend. – w0051977 Apr 9 '18 at 14:41
  • @David Arno, could you explain why it is not a value object? It is immutable. It does have behaviour but the behaviour doe snot modify the state. – w0051977 Apr 9 '18 at 14:42

If the class is called once by an application service then a domain service is appropriate.

I would normally expect a domain service to be invoked by the domain model; the domain model is typically used to give the aggregate access to information or capabilities outside of its own boundary.

Can a Value object exist on its own?

Fundamentally, "value objects" exist because (a) Domain Driven Design was first documented in a context (Java) where everything is an "object", and (b) because we want a representation that is more specific than the domain agnostic primitives provided by the language runtime.

So asking "can a value object exist on its own?" is analogous to asking "can the integer 7 exist on its own?"

We won't normally have a repository for 7; we'll load and store that value as part of the representation of the state of some entity, via its repository. The same is true for value objects - they won't have a life cycle of their own.

That said, its fairly common for value objects to be passed as arguments, detached from any particular entity, in much the same way that we pass integers as arguments. We do that when the receiver doesn't/shouldn't care about the context from which the argument was fetched.

An interesting problem is what to do when an aggregate needs access to data loaded from somewhere else? I believe that Evans used the example of a tax table in the blue book; here it might be your list of denominations. So you might be asking "should I pass a domain service, or an immutable value object, to this aggregate that needs access to this externally stored state". My guess is that, in the long run, passing in a domain service will be the more flexible option. But I don't think I've seen a good study of the alternatives.

  • I would argue for the latter. When "state from somewhere else" is a required piece of a given transaction, a domain service should be introduced to encapsulate that transaction. For example, imagine withdrawing money from an ATM: the Atm.Withdraw transaction requires knowledge of/depends on Account.Debit (funds must be available). In this case, an AtmService must be introduced to coordinate the transaction between the Atm and Account entities. Injecting a domain service would be giving either entity too much knowledge. Now, it's reasonable to argue that, unlike my example, the... – king-side-slide Apr 9 '18 at 15:13

It looks like you're mixing up two different issues. The question's title is a separate problem from what you ask in the contents.

  • Can a Value object exist on its own?

I'll repeat what I wrote in the SO answer you mentioned - to me, a Value Object can perfectly exist on its own in a transient way. Why would a Currency, a Country or a Color necessarily be tied to one type of Entity? This would also prevent Domain Services from using Value Objects other than ones they get through Entity references, which is kind of odd.

This part of the article you linked to seems like a non sequitur to me:

Value objects, at the same time, have a zero lifespan. We create and destroy them with ease. That’s a corollary of being interchangeable. If this 1 dollar bill is the same as another one, why bother? We can just replace the existing object with the one we just instantiated and forget about it altogether.

A guideline that flows from this distinction is that value objects cannot live by their own, they should always belong to one or several entities. The data a value object represents has a meaning only in the context of an entity it refers to.

I fail to see the link here. Again, why would non-entity objects be forbidden to create and manipulate Value Objects in their own context?

  • What are good criteria to choose between Value Object and Domain Service?

1) If the class is called once by an application service then a domain service is appropriate.

2) If the class is used by an entity or other value object then a value object is appropriate. Note that my first link above seems to contradict this.

I apply different criteria. Use a Domain Service for logic that is at the crossroads of multiple Entities. In contrast, a Value Object is only concerned with its own data - it almost never knows about an Entity.

  • with regards to your last paragraph - in this case there are no entities or value objects – w0051977 Apr 9 '18 at 10:05
  • In what case? What do you mean? – guillaume31 Apr 9 '18 at 10:57
  • I am saying that in my case; the domain service exists on its own i.e. it is not logic that is at the crossroads of multiple Entities. That is why I am asking if it should be a domain service. Apologies for the confusion. – w0051977 Apr 9 '18 at 14:44
  • Sorry, I can hardly be helpful about your specific context with that little info about the domain. I don't even get what a denomination is. – guillaume31 Apr 9 '18 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.