I'm reading on DDD and came across this excerpt:

Let’s consider a drawing application. The user is presented a canvas and he can draw any points and lines of any thickness, style and color. It is useful to create a class of object named Point, and the program could create an instance of this class for each point on the canvas. Such a point would contain two attributes associated to screen or canvas coordinates. Is it necessary to consider each point as having an identity? Does it have continuity? It seems that the only thing that matters for such an object is its coordinates.

By now I'm confused, the question

Is it necessary to consider each point as having an identity? Does it have continuity?

Clearly it's a disapproval question, meaning we cannot consider a point class, an entity class. But to my understanding of DDD, any object with unique identity (in this case, coordinates of the point) is considered an entity.

The excerpt from "domain driven design quickly" book

  • 1
    I'm trying to think of a helpful answer here but there doesn't seem to be a question. For a point in space, it's coordinates is it's identity. If you just want to understand the point the author is making (no pun intended), I think there's not enough context here to do that. – JimmyJames Sep 6 at 19:43
  • I don't think the author considerd the point an entity class.. Do you think he didn't? – mshwf Sep 6 at 21:09
  • 1
    I think he doesn't. I probably wouldn't either but I'm not the best person to ask about the formal definitions of things. From a usefulness perspective, I wouldn't consider a point a entity unless your domain model has a concept of a point. Usually this kind of thing is used to represent your entities but is not one in itself. I think of a domain model as being highly abstract. Trying to work out your domain entities based on which objects have identities seems completely backwards. – JimmyJames Sep 6 at 21:43
up vote 3 down vote accepted

It seemed at first sight to be a very obvious answer. But the most obvious things are sometimes the most difficult to explain :-)

Let's take your drawing software example. Suppose you have two shapes: a red circle (C) and a blue line (L) that intersects, and imagine that Point would have an identity that is uniquely determined by it's coordinates:

  • First consider that Point has no other attributes than its coordinates:

    If there are no other attributes, and the coordinates are the identity, then there is no continuity of the identity, because whatever you change on a Point, you'd loose the identity.

  • Then, take one of the two intersection points of (C) and (L) and call it M:

    The identity of M should define the other attributes of Point such as for example Color. But what would the unique Color of M be: red because (C) was drawn first ? blue because the (L) was drawn last ? purple because it's the addition of red and blue ? Or does the color associated to the point depend of the shape you consider the point in ? In the first case, the point seems to have a fuzzy identity. In the later case the point would have several identities (id would require more than the coordinates).

  • Then, let's have a second look on the continuity of the identity:

    The red circle has it's own identity: it is defined by its name, (C). And beside it's center and radius, it is also composed of a set of points that satisfy a mathematical relationship. What happens if we move (C) ? Its identity has not changed, so it's the same circle, just with another center. As it's the same circle and its points have an identity, and as we have a whole/part relationship we would expect to keep the same set of points and just move them, shouldn't we ? But every point we move looses its identity !

All this shows us that if points would have an identity, we would have a couple of contradictions and inconsistencies (or at least counter-intuitive situations). This is why Points should best be considered as value objects in this example. Here the definitions:

ENTITY An object fundamentally defined not by its attributes, but by a thread of continuity and identity.

VALUE OBJECT An object that describes some characteristic or attribute but carries no concept of identity.

-- Eric Evans

An entity has a concept of identity that is independent of its value.

For the concept of a Point, are two separate point-objects Point(x: 1, y: 2) and Point(x: 1, y: 2) considered the same?

  • If they are entities, then the points might have different identities and would then be different.
  • In practice, a point is likely to be identified by its coordinates. The two points would then be equal. The point is a value type, not an entitity.

Now we might use a different representation. The points don't contain the coordinate, but are stored at a particular coordinate, e.g. raster[1][2] = Point(). Are two point objects Point() and Point() considered the same?

  • Each point instance might now represent a different coordinate, so they might be different.
  • If they were value types they would all be the same because they are empty.

So whether a concept is modelled as an entity or value type depends on the context, and sometimes on the rest of the model.

Entities are often given a (synthetic) ID to keep track of them. Within a programming language this could be the object's memory location, but that is only a transient identifier. More often, an explicit ID is generated, for example to be used as a primary key in a database – although the database concept of “entities” is slightly different.

It depends on your model.

Suppose the drawing application is like MS Paint. Then you would have a document, being a bitmap. The pixels in the bitmap are colored according to the user's actions. There are no point objects, there is just one bitmap that changes as the user performs his painting actions.

Now suppose the drawing application is like Scribble. You may not know Scribble, in scribble the document is a series of strokes. One stroke consists of a series of points.

In the second model you will have point "objects". Although you may want to implement them as value types, you will be keeping track of individual points and these will be stored as points, the points will be (de)serialized. Points from different strokes may have identical co-ordinates, yet they will be different individual objects.

In the Paint model the location of the pen may be an object whereas the pixel being colored may not be presented by an object. It all depends on context (who cares about that object, would it have a purpose?). You can recognize an object in every detail but at some point you should stop modeling because your problem is solved and pushing OO design further no longer serves a purpose. It may then even degrade the application due to excessive resource use or introduced performance issues.

You can "identify" value objects by their values!  However, they are immutable.  Two identical value objects are the same value.  If you want another value you just create it — you don't have to tell anyone.  In and of themselves, values are not captured authoritatively; they don't represent system state.

We generally don't catalog mere values on their own in a database (table), because such a value's key/identity would be all its attributes.  (And also because what would you put in the table: all possible values?)  Using such a value from another table would just repeat the whole thing in the foreign key.

An entity, on the other hand is a (generally mutable) association of a stable identity and other values (and/or other entities, e.g. their identity values).

Values don't mean anything on their own, whereas entities make assertions or statements of fact on the record, that there is this thing that currently is recorded to have these particular attributes.  Such statements are collected and captured and compose into system state.

Taking a point as an example, let's expand it to include a color.  Now we can look at one such colored point as a mere value in the space of all possible colored points — treated as such that makes a colored point a value.

Or, we can look at a colored point as a point identity associated with a particular color — as a matter of record — as a matter of captured system state — that is captured by a designated authority.

An authority like a particular table in a particular database, or an in-memory collection or other data structure meant for this capture, such as a canvas.

The difference is whether we are authoritatively capturing such colored point as a statement of record, which means that if I say this point 1,2 has this color, blue, then any other color for that particular point should be considered untrue -or- would require a change in state of the system of record.

Treated this way, the colored point is an entity — because we are capturing the current value of the entity.  Given an authority, we can ask: what is the current color of 1,2?  We can't do that with mere values alone — there is no authority to ask!

Further, another color for that same point cannot simultaneously coexist, so assigning another color to that entity requires a formal (transactional) update to the formally captured, authoritative system state.

In short, a colored point is just a value unless it is in the context of an authority that captures the current color of point entities.

Is a point drawn on a canvas considered an entity in domain driven design?

Yes, if you consider the canvas as an authority and system of record that, from the DDD perspective, communicates with the world outside the bounded context regarding the points' identities, as their own aggregate root in a common canvas, or as multiple canvases attached to other aggregate roots.

Each point is conceptually an entity on the canvas — but that doesn't necessarily mean that each point needs to be manifest as its own object instance: there are lots of possible (better) implementations.

The choice of making an object an entity type or a value type is completely arbitrary.

Clearly you could have a drawing app where you drag points around and need to allow for two distinct points with the same coordinate.

Or a "guess who" game where two 'people' with the same properties are the same person.

Value and Entity types are real things in code, but you can't tell from that kind of brief requirement description which would be the better choice for the various verbs

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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