Users are often asked to create new entities for a software system. When you're creating a new entity you're often in the situation where you are gradually filling in pieces of an incomplete object. Sometimes you can do all of this on a single form, but more complicated entities need multiple forms, so the software needs to maintain what the user has entered so far. Commonly this is done in some form of SessionState - state that's only relevant during the length of the session.

A creation object takes this temporary data and elevates to a fully modeled entity - treating this input mechanism as its own first-class concept.

Creation objects are often shadows of a long-term persistant entity. If you're building up information for a hotel reservation, then the properties of the proposed reservation are often similar to a booked reservation. I've heard this pattern described informally in this style as proposed object, with the implication that the adjective "proposed" should be used to signal its use.

Despite this similarity I think its generally more useful to model the creation object from a different perspective. When working with a creation object, your focus is on data and behaviors that support the creation process. As a result a proposed reservation may look quite different to the booked reservation that lasts longer. This focus on the operation of creation also separates a creation object from using ContextualValidation on the reservation as a single concept.

When you use a creation object you often take the verb trying to create something (registerUser) and turn it into a noun for the process that the verb describes (registration), which is why I sometimes hear this referred to as a reified operation.

This difference between the proposed object and its committed form is also a reason to name it differently. A good example of this is the relationship between a shopping cart and an order. You can think of a shopping cart as a proposed order, but the different metaphor and naming helps reinforce important differences in behavior.

Creation objects are like session state in that they are usually isolated from the application as a whole - although its generally useful for an application to use information about such works-in-progress to help understand a user's characteristics and to aid planning for when the creation object is fulfilled.

There are many advantages to taking this kind of data out of session state and into a creation object. These days users like to access information from lots of different devices, so even in a relatively short business transaction it's useful to allow people to work across sessions. The more complex the creation process is, the more useful it is to reify it into its own concept.

Most examples of creation object that I come across involve the creation of a long-lived entity, but the pattern also makes sense for some modifications of an entity. It's less common for modifications because modifications are more likely to be rapidly committed. However sometimes people need time to form a more involved change - so treating the modification as a first-class concept makes sense. [1]