Mon Oct 28, 2002 8:08 am
Eric,
Great book!
I really sympathise with the message about complexity.
My interests are in ontologies, particularly for semantic integration - which will be obvious when you read my question.
You make it plain (some extracts copied below) that there are two types, entities and values, and there is a design choice about whether to represent the things in the domain as one or the other - motivated by considerations such as performance and complexity. This is a sensible position when considering how to design a particular application.
However, a certain amount of the complexity in modern applications arises from the need to integrated them. In this case, the division into types is potentially misleading as an entity in one system can be a value in another. There seems to be a trade-off here between designing for one application and designing for integration. There also seems to be some constraint on re-usablility - as a different application may well want to represent the object as a value and so cannot re-use the first design that takes it as an entity.
While the division into entity and value is, I am sure, sensible for implementation - I want to suggest that it is possible to do a different analysis can be done pre-implementation that will make integration (re-use) easier. Taking your example of the child and her crayons. In the process engineering industry (see ISO 15926) they distinghish between the crayon entity (in your sense) and the crayon value (in your sense) calling them respectively material and facility. The crayon facility has an identity (in your sense) that is dependent upon the child. I.e. if the crayon is given to another child it is no longer the 'same' crayon (though ISO 15926 is more likely to talk about the same pump).
My intuition and experience tell me that it is possible to do this with many (all?) of the other examples that you provide.
I am not claiming in any way that the distinction between entity and value should not be made in the design of the application. I just wonder whether a more application-independent model of the domain should be a precursor to this kind of design decision? At least in circumstance where re-use and integration are of importance.
What do you think?
Regards,
ChrisPartridge
----------------
Extracts
From p.46.
"The job of expressing the concepts of the model falls primarily to three categories of objects. Most conspicuous are ENTITIES, those objects that represent some element in the domain that needs to be tracked and identified. In contrast, VALUE OBJECTS are important only in the information they carry and the computations they can perform. They are often attached to ENTITIES to describe them, but they are not tracked in their own right. Finally there are those aspects of the domain that are more clearly expressed as actions or operations, rather than as objects. Although it is a slight departure from object-oriented modeling tradition, it is often best to express these as SERVICES, rather than forcing responsibility for an operation onto some ENTITY or VALUE OBJECT."
p. 49 "The model must define what it means to be the same thing. Identity is not intrinsic to things in the world, it is a meaning superimposed because it is useful. In fact, the same real-world thing might or might not be represented as an ENTITY in a domain model."
p. 56 "An object that represents a descriptive aspect of the domain that has no conceptual identity is called a VALUE OBJECT. VALUE OBJECTS are instantiated to represent elements of the design that we care about only for what they are, not who they are."
p.55 "If a child is drawing with markers, he cares about the color of the marker he chooses. He may care about
the sharpness of the tip. But if there are two markers of the same color and shape, he won?t care which he
uses. If a marker is lost and replaced by another of the same color from a new pack, he can resume his work
unconcerned about the switch.
Ask the child about the various drawings on the refrigerator and he will quickly distinguish those he made
from those his sister made. He and his sister have useful identities, as do their complete drawings, but
imagine how complicated it would be if he had to track which lines in a drawing were made by each
marker. Drawing would no longer be child?s play."
Chris Partridge
Very interesting points, Chris. I'm sorry I've been so slow in
responding. I got a little buried preparing for OOPSLA, etc.
On reading your message, I realized I hadn't quite made my point
clear. The distinction between Entities and Values is a semantic
distinction. My extensive discussion of performance issues was
intended to explore the consequences of certain model choices.
> There also seems to be some constraint on
> re-usablility - as a different application may well want to
> represent the
> object as a value and so cannot re-use the first design that takes
> it as an entity.
Yes, if one system views an object as a value and the other views it
as an entity, they will be difficult to integrate, because they have
different semantics in their models. This was a point I had intended
to make, but it may not have come through very clearly. If two
systems want to share an object, they had better agree on whether it
is an entity or a value. In the entities section, I pointed out how a
Customer object might take quite different forms on different
systems, but still have the same identity and allow the exchange of
data.
Of course, the fine-grain breakdown could be different. (I tend to
keep entities very lean, and attach values to describe them partly
for this reason, but the difficulty still arises.) For example, if
the crayon's ownership is being tracked (if I understand your point)
then you are right, the crayon is an entity. The color could be
modeled as an attribute of that entity (a numerical color value) or
as a value object associated with that entity. The latter would be a
more explicit model that communicates the semantics better.
But I am a little suspicious of application independent designs. When
people start tracking the ownership of crayons just on principle or
just in case, I think it actually obscures understanding. If someone
has figured out that noone cares which crayon is which, it is an
important piece of knowledge that should be reflected in the model.
It also keeps things simpler. If this turns out to have been a wrong
decision (because some system that we have to integrate with does
care) then the model will have to be changed.
Did that clarify my meaning? And, if so, do you agree?
By the way, if you are interested in semantic integration between
systems, be sure to read Chapter 14, "Maintaining Model Integrity".
I'd like to hear your comments on that chapter.
EricEvans
TypesAndSematicIntegration is mentioned on: ThreadView
