Related
In Domain Driven Design,domain objects are fall into two categories,entity and value object.It is very easy to make out which is entity,which is value object,but i don't know why we have to do that?Before the advent of DDD, we model the domain without entity and value object.After the DDD was put forwar,we use entity and value object to classify domain object, so what is the advantage of such classification?
domain objects are fall into two categories,
Actually, no, objects are a possible implementation of a domain Concept , which is basically just information, not code. A concept can be an Entity because it makes sense to identify it in a uniquely and consistent manner, regardless how it changes over time (e.g: a Customer can change their name but it's the same customer. 2 customers with the same name are not necessarily the same person).
A Value Object (a name that still reminds us that DDD started a bit too coupled to OOP) represent a Domain concept that it's just a value. Or more precisely, the business only cares about its value. If you change it, it's another value all together. Basically, 5 dollars is 5 dollars, you don't really care which is which, any of them is good enough, because only the value is important.
Another thing is, as a domain modeler you identify the nature of a concept based on how the business looks at a concept. The business tells you what they care about.
Now, that we know that a concept can be a Entity, we can select a certain instance of it (User with Id 3). You can't do that with VO, because a VO doesn't have an identity.
Even more, when we identify aggregates, most of the time, the aggregate components (other concepts) are mostly VOs, because they usually are just values (but they do respect business constraints).
So, in conclusion, we classify concepts into Entity and VO, because
The business sees them in this manner: uniquely identifiable or just value
Entities keep their identity regardless how they change (obviously the identity itself is read-only), we treat each one as unique
VO are values that can be used interchangeably, we don't care which is which as long as they represent the same value (which itself, as an implementation detail can be a complex - composite - value). Also, a VO by its nature is immutable, so we know that we can't change it without becoming another value.
Before the advent of DDD, we model the domain without entity and value object.After the DDD was put forwar,we use entity and value object to classify domain object, so what is the advantage of such classification?
You should review Chapter 5 ("A Model Expressed in Software") of the Blue Book.
Evans writes:
Defining objects that clearly follow one pattern or the other makes the objects less ambiguous and lays out the path toward specific choices for robust design.
Tracking the identity of ENTITIES is essential, but attaching identity to other objects can hurt system performance, add analytical work, and muddle the model by making all objects look the same.
... bidirectional associations between two VALUE OBJECTS just make no sense. Without identity, it is meaningless to say that an object points back to the same VALUE OBJECT that points to it. The most you could say is that it points to an object that is equal to the one pointing to it, but you would have to enforce that invariant somewhere.
My own summary would be this: recognizing that some domain concepts are entities is useful, because it encourages the designer to acknowledge that identity, continuity, and life cycle are important concerns for the entity in this domain. Similarly, recognizing that a concept is a value immediately frees you from those concerns, bringing your attention to their immutable nature and equivalence.
When I started using DDD, I created Equals() methods in my entities that compared the ID of the entity. So two entity objects with the same ID would be considered equal.
At some point I thought about that and found that two entities in different states should not be considered equal, even when they describe the same thing (i.e. have the same ID). So now I use reference equality for my entities.
I then stumbled over this answer by Mark Seemann, where he writes
Entities are equal if their IDs equal each other.
Now, of course, I'd like to know which approach is better.
Edit: Note that the question is not whether having two instances of the same entity at the same time is a good idea. I'm aware that in most situations it is probably not.
The question is twofold. First, what you really want to know is
How to handle terms that the X language (or Y framework) impose when I code a domain model with it?
C# for example imposes you that any new concept you define inherit a certain set of public methods. Java includes even more methods.
I've never heard a domain expert talking about hash codes or instance equality, but this is one of those situations when the (often misunderstood) quote "don't fight the framework" from Evans apply: just teach developers to not use them when they do not belong to domain's interfaces.
Then, what you want to know is
What is an entity? How it relates to its own identity?
Start with why! You know that entities are terms of the ubiquitous language that are identifiable.
But WHY?
Plain simple: entities describe concepts whose evolution in time is relevant in the context of the problem we are solving!
It is the relevance of the evolution that defines the entity, not the other way around! The identity is just a communication tool to keep track of the evolution, to talk about it.
As an example think about you: you are a person with a name; we use your name to communicate about your interactions with the rest of the world during your life; still, you are not that name.
Ask yourself: why I need to compare domain entities? Is the domain expert talking this way? Or I'm just using a DDD parlance to describe a CRUD application that interact with a relational database?
To me, the need to actually implement Equals(object) or GetHashCode() into an entity looks like a smell of an inadequate infrastructure.
Entities shouldn't be compared like that, in the first place. There is no valid use case (outside testing, but then again the assertion library should handle this for you) to see if 2 entities are equal using the object's Equals method.
What makes an Entity unique is its Id. The purpose of the id is to say 'this very entity is different from other entities despite having identical properties/values'.
That being said, in a Domain you might need to compare a concept instance with another instance. The comparison is done according to Bounded Context (or even Aggregate) specific Domain rules. It doesn't matter an entity is involved, it could have been a value object as well.
Basically the 'comparison' should be a Domain use case which will be probably implemented as a service. This has no relation to an object's Equals method, which is a technical aspect.
When doing DDD, don't think like a programmer (i.e technical aspects) think like an architect (high level). Code, programming language etc is just an implementation detail.
I think it's bad idea to have the two separate instances of the same entity in different states. I can't think of a scenario where that would be desirable. Maybe there is one? I believe there should only ever be one instance of a given entity with a particular ID.
In general I'd compare their equality using their IDs.
But if you wanted to check if they are the same object reference then you could just use:
if (Object.ReferenceEquals(entityA, entityB))
{
DoSomething();
}
I drives me crazy how many books contradicts themselves.
Class A {} class B {void UseA(A a)} //some say this is an association,
no reference is held but communication is possible
Class A {} class B {A a;} //some say this is
aggregration, a reference is held
But many say that holding a reference is still just an association and for aggregation they use a list - IMHO this is the same, it it still a reference.
I am very confused, I would like to understand the problem.
E.g. here: http://aviadezra.blogspot.cz/2009/05/uml-association-aggregation-composition.html - what is the difference between Strong Association and Aggregation, in both cases the author uses a field to store the reference..
Another example:
This is said to be Association:
And this is said to be Aggregration:
public class Professor {
// ...
}
public class Department {
private List<Professor> professorList;
// ..
}
Again, what is the difference? It is a reference in both cases
This question has been, and will be, asked many times in many different variants, because many people, including many high-profile developers, are confused about the meaning of these terms, which have been defined in the UML. Since the question has been asked many times, it has also been answered many times. See, e.g. this answer. I'll try to summarize the UML definitions.
An association between two classes is not established via a method parameter, but rather via reference properties (class attributes), the range/type of which are the associated classes. If the type of a method parameter is a class, this does not establish an association, but a dependency relationship.
It's essential to understand the logical concept of associations first, before looking at how they are coded. An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown below, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.
An association is always encoded by means of reference properties, the range/type of which is the associated class. For instance, like so
class Committee { ClubMember chair; String name;}
In the UML, aggregation and composition are defined as special forms of associations with the intended meaning of classifying part-whole-relationships. In the case of aggregation, as opposed to composition, the parts of a whole can be shared with other wholes. This is illustrated in the following example of an aggregation, where a course can belong to many degree programs.
The defining characteristic of a composition is to have exclusive (or non-shareable) parts. A composition may come with a life-cycle dependency between the whole and its parts implying that when a whole is destroyed, all of its parts are destroyed with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. An example of a composition where the parts (components) can be detached from the whole (composite) and therefore survive its destruction, is the following:
See Superstructures 2.1.1:
An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. Composition is represented by the isComposite attribute on the part end of the association being set to true.
Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends.
Your above examples are on different abstraction levels. Department/Course are concrete coding classes while Department/Professor are at some abstract business level. Though there is no good source (I know) explaining this fact, composition and aggregation are concepts you will use only on business level and almost never at coding level (exception below). When you are at code level you live much better with Association having role names on both sides. Roles themselves are a different(/redundant!) rendering of properties of a class that refer to the opposite class.
Aggregation as a strong binding between classes is used e.g. in database modeling. Here you can delete a master only if the aggregates have all been deleted previously (or vice vera: deleting the master will force deletion of the aggregates). The aggregate can not live on its own. The composition as in your example is (from my POV) a silly construct as it pretends to be some week aggregation. But that's simply nonsense. Then use an association. Only on a business level you can try to model (e.g.) machine parts as composite. On a concrete level a composition is a useless concept.
tl;dr;
If there is a relation between classes show it as simple association. Adding details like roles will aid when discussing domain details. Use of composition/aggregation is encouraged only when modeling on business level and dis-encouraged on code level.
I've written an article about the differences between UML Association vs Aggregation vs Composition based on the actual UML specification rather then interpretations of book authors.
The primary conclusion being that
In short, the Composition is a type of Association with real constraints and impact on development, whereas the Aggregation is purely a functional indication of the nature of the Association with no technical impact.
Navigability is a completely different property and independent of the AggregationKind.
For one thing, UML is a rich language, meaning there is more than one way to describe the same thing. That's one reason you find different ways described in different books (and conflicting answers on SO).
But a key issue is the huge disconnect between UML and source code. How a specific source code construct is represented in UML, and vice versa, is not part of the UML specification at all. To my knowledge, only one language (Java) has an official UML profile, and that's out of date.
So the representation of specific source-language constructs are left to the tool vendors, and therefore differ. If you intend to generate code from your model, you must follow the vendor's conventions. If, conversely, you wish to generate a model from existing source code, you get a model based on those same conventions. But if you transfer that model to a different tool (which is difficult at the best of times) and generate code out of that, you won't end up with the same code.
In language-and-tool-agnostic mode, my take on which relationships to use in which situations can be found here. One point there worth repeating is that I don't use undirected associations in source-code models, precisely because they have no obvious counterpart in actual code. If in the code class A has a reference to class B, and B also has one to A, then I draw two relationships instead.
I found a definition for association in UML as below.
An "association" in UML is defined as a kind of relationship between
classes,which represents the semantic relationship between two or more classes that
involves connections (links) among their instances .
I am not clear what is semantic relationship. Can anyone explain it with example with comparing it with non semantic relationship?
Associations in plain text
An association is a semantic relationship. The UML clause means that there is a structural relationship between instances of the associated classes independently of any specific implementation. "Semantic" underlines that the relationship is between the instances themselves, and not just "accidentally" for an operation:
Use associations primarily where there are structural relationships among objects. Do not use them to show transient relationships such as parameters or local variables of procedures.- Booch, Rumbaugh & Jacobson in Unified Modeling Language User Guide, 2nd edition
More arguments
What is "semantic"?
The term "semantic" is borrowed from linguistics and refers to the meanings behind the words. Linguists and map words (e.g. "Car", "Driver") to their meaning (e.g. a real car, a real person), and analyze the relation between words with a view of this mapping:
So, applying this to UML (modelling language) if you'd have the classes Car and Driver, you CAN model the semantic relationship as an association between the two classes.
What is not semantic?
Not all relationships are of semantic nature. You can have dependencies, which can express a technical relationship:
a transient relationship during an operation: with a factory pattern for example, a DriverFactory would «create» a Driver instance. Both instances the factory and the driver are related only at the exact moment of the creation operation. But the two instances are completely independent the nanosecond after.The same applies if the implementation of an operation needs to create a local instance of another class. Both classes are not associated, since we could imagine another implementation that works without such an instance.
a structural dependency: Maybe an operation require some other classes as parameter. Since the parameters themselves are transient, there is no association. But nevertheless, teh class needs to know about the other class.
For the records, I'm grateful to this public domain contributor for the nice car and driver and to 18f for advice on inclusive communication.
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
A model says something about the things being modeled. This is its semantics. Almost all elements of UML have semantics, defined in the sections titled "semantics". One exception is the comment. Adding a comment to a model doesn't influence its meaning.
Then why does the UML say this explicitely about associations? The reason is, that an association may or may not say something about the structure. If it doesn't, it is purely semantic.
For example it could tell us, that a Car can have at most one Driver. It doesn't necessarily mean that the car has an attribute of type Driver.
If we want to model that the two associated classes own attributes typed by the other end of the association, the notation will show this by small dots on its ends. Many people are not familiar with this notation and interpret associations without a dot in the same way. However, without the dots attributes are owned by the association itself and the structure of the classes is not influenced.
By the way, a class being the type of a parameter of an operation or having a dependency also means a semantic relationship.
I have some questions regarding some DDD concepts:
In Evans' book about DDD, in section VALUE OBJECTS, he says to put attributes that make up a conceptual whole in VALUE OBJECTS like in his Address objects example. I can't seem to see the benefits of this than just leaving the attributes inside the Customer entity. What would I gain by moving it out of the Customer, making it a VALUE OBJECT, and then referencing the VALUE OBJECT back in the Customer? Please cite some practical example.
Can SPECIFICATIONS be used on VALUE OBJECTS too?
Are all properties of ENTITY OBJECTS either other ENTITY OBJECTS and/or VALUE OBJECTS? Or can they have primitives?
Browsing the internet, I've seen some saying that setters (and getters?) are evil, that they should be avoided and replaced by operations that makes sense for the domain object.
For example:
Account.Balance = 100; // set via property setter
Should be:
Account.DebitToAccount(100); // this would change the balance
In this example, I can understand what they are implying but what about for some common properties like FirstName, MiddleName, LastName? I think it's tedious and pointless to have methods for each property just to set them (like ChangeName()). And assuming that we've chosen to have a method like ChangeName(), what about for properties that have no other groupable property? For example, say Title? Should we have a ChangeTitle() too? (Title is just an example, please don't say that I can group Title to some other property)
Encapsulation of a domain concept. An Address is not just any string , a Price is not any number/decimal . VO represents a valid value of a Domain concept expressed as an object. Note that 'a' value doesn't really mean encapsulation of 1 primitive. You can see here an example of how I've modeled some value objects.
No.
It's not a rule. A property of an entity should be of type that makes more sense. Some represent domain concepts, other represent more general concepts (like Email) and other are just primitives.
Not really DDD, that's proper OOP. The point is you want to encapsulate behaviour. Setting a property is just a simple assignment. DebitToAccount is a semantic behaviour of the object that may be implemented only as a property assignment. Things can easily change and you want only that object to know about those implementation details. The behaviour itself stays, implementation can change anytime (ex: a new business rule is required).
At least in C# you don't really need ChangeName(), you can put the implementation in a setter. There aren't rules, not even principles in this scenario, it depends on developer style.