This post is actually a question:
Is there any word for an entity/object that not yet have any value to the domain at hand?
e.g. an entity like a document that can be edited until some point in time where it gets processed and the result is then used in some domain action.
Lets say I download a job application in PDF format and save on my computer, I can edit the data in the application over and over and re-save and the state changes/transitions are not interesting to anyone.
The objects state only become interesting once it enters the domain it belongs to.
Another example could be a shopping cart, OK, I know that there might be actual domain logic attached to a shopping cart in many cases.
But if we look at it in real life with a real physical shopping cart, nobody cares if I add or remove items to my cart until I go to check out.
Or maybe a draft email, I can edit and change it in any way I want and it is not until I press “Send” that the contents/state of the object becomes important, even if the object is persistent. (I can re-open my draft and continue so it is persisted)
The reason I got to think about this is because this is actually a case where it will be OK to map from DTO to entity straight of w/o any implications.
Many people (including me) in the DDD community don’t like to map from DTO to entity because you lose semantics and intention.
But I was thinking about this today and in that kind of case, that might be a completely valid approach.
This is a special kind of object that does not need the same design considerations as a “normal” domain entity would have.
That is the key here, it doesn’t have any domain value and therefore the design can be lighter/simpler than we otherwise need/should use.
That is, before it gets any value to the domain at hand. you simply map it from DTO to entity in order to make it persistent and it doesn’t matter if you lose intention here since it does not yet hold any value to anyone, you just save it so you can continue edit it later.
And at some point in time, pass it into the domain.
(Am I repeating myself now?)
Agree? disagree?
[Edit]
My friend Henric @fat_coder suggested that this might be a command.
Maybe it actually is?
Could it be that a command could be persistent and editable before it is sent of to a command handler?
Interesting thought..
I do like the idea, it could be a ApplyForJobCommand in the job scenario, and a CheckoutCommand in the shopping cart scenario.
Roger Johansson Blog 
I would rephrase the first question to: Is there any word for an entity/object that, all though it has values, it not yet have any worth to the domain at hand?
You are talking about an object that have intermediary values, they are just not of interest to the domain until the user submit them.
I solve this but a status field, an enum that one of the possible values is “Been Edited”. But if you are asking about a name… I don’t think it is about naming it but stage. The object exists and it has all the semantics that it needs, it is just in gestation, it has not been born into the domain yet. The object type it self has already been determined. This is more about data flow than data type. Once the object is completed and submitted it will not change its type, only its availability to the domain.
Jorge
@jorge , this can absolutely be modeled like a normal entity with a status flag, but in such case, one should apply the same design considerations to the object as for a normal entity.
e.g. you will probably be better off sending state changes as commands (like the C in CQRS) since you carry semantics then. which you probably want if the same infrastructure applies once the flag described above is set.
I do not like the idea of mapping DTOs to entities since you will get into problems because there is no state transition validation if you do so.
But in a case where state transitions doesn’t matter, it would be a valid approach, I guess.
I think Jorge is on to something. I like the notion of a “prentity” though. :) It might not matter to the domain yet because no command related to it (or if is one itself) has been issued yet, but depending on usage, it might matter to the user. It is indeed in gestation and what Jorge says about “data flow not type”. But I personally think a prentity needs to be a thing. :)
Ugh… WP lost my comment…
I don’t really know fo sure, but I either imagine it as a transient object of some sort that might generate a command that is sent to a command handler or as you mention in your edit, an editable command that is “in gestation” as Jorge mentions. But I really like the “prentity” idea! :)
Oh, there it is! :)
There are multiple ways to implement this in a DDD manner.
You may want to make the status change into a flag that makes the entity cross context boundries. The gestational stage is one CB, while the system acting on it another. In this case, your command should raise a message so the next context can act upon the new born entity.
Another way is to make the C of the CQRS observable, so the rest of the system can listen to when this change happens. I admit that this path might look more sexy, but it can also be more fragile.
Please notice that neither of them has to do anything with the DTS. The way that I am used to do DDD, I make the storage as dumb as possible, all though I understand that there can be many schools of thoughts about this topic.
This is a very interesting topic for me, and I enjoy this kind of posts. Thank you for the openness when blogging he question.