Some books describe it as a 1:m association between classes A and B with an implied 0..1 label at the diamond end, while others see it as a 1:1, 1:m or m:n whole-part association. Which one is correct?
Thanks!
All versions are correct, they key of aggregation is not cardinality (1:1, 1:m or m:n) it can has anyone of these you mentioned.
The key is that even when e.g. an instance of B is in an instance of A, if you destroys A, B remains.
e.g.: A company has clients and clients will still existing when company disappears (aggregation) but employees won't to be employees when company disappears (composition).
Not my best analogy but representative enough I guess.
It's like in databases and for me this view is more clear, a table with a foreign key will be aggregation and relational 3rd table is composition.
Related
I want to model an airport and a city and would like to choose the appropriate decomposition relationship between the two but I cant seem to make up my mind which one to choose as they both have different relationships.
A City can exist on its own and does not require an airport hence I would say that City-Airport link is an aggregation however...
An Airport requires a City and will not exists without one making it a Composition relationship.
Is it possible to have two relationships? One which is City -> Airport and the other being Airport -> City it does feel strange however since a Composition to me feels like a relationship which should be honoured by two people and not just one.
It's a widespread misunderstanding that the relationships between classes are primarily either "aggregations" or "compositions". I think this unfortunate tradition has been extablished in the C++ community.
Rather, the most important kind of relationships between classes are "associations", as they are called in UML class models/diagrams. So, if you want to model the relationship between Cityand Airport, you probably want to choose a one-to-many association (since a city may have more than one airport, but any airport is assigned to a city).
In UML, both aggregations and compositions are special cases of associations, used for expressing a part-whole relationship between the instances of both classes. Since an airport is not really a part of a city, but just related to it, there is neither a Composition nor an Aggregation between Cityand Airport, but just a plain Association.
In many cases, where we may wonder if an association is a composition, it is safer to model it as a plain association.
The only good reason for modeling an association as a composition is when the instances of the component type are "weak entities" not having their own identity (object ID). But airports do have their own ID, so there is no need, and no gain, to model them as components of a city.
I've looked at 2 other questions that seem related:
Is Aggregate Root with Deep Hierarchy appropriate in DDD?
How to define DDD Aggregate root for hierarchical data structure?
However they're not exactly the same as my situation; maybe missing the "constraint" aspect.
My situation: I have an AR named "Study", and a Study can be organized by cluster (borrowing from clustered-sampling concept in survey domain).
Let's say this "Study" takes this parameter "clusteringDepth" (an integer) in is constructor. Let's say: I specify 3 (provinces, counties, cities).
That's just a spec. of a Study. When you actually conduct a study, you create an instance of StudyPlan based on the Study.
So, in this case I will have an instance of StudyPlan that has a list of provinces (first-level clusters). Each province, has a list of counties (second-level clusters), and each county has list of cities (third / final-level clusters).
On each cluster you can attach quota information, and date range (specifying how many interviews you have to raise in that cluster, and the date interval for the interviews). Obviously a parent cluster must maintain invariants like "sum of quotas of child clusters must be less or equal to the quota of this cluster".
Ok..., now, the constraint: you can plan an interview with a respondent. For that you'd create an instance of InterviewPlan. But..., this interviewplan can only be attached to terminal (third-level) clusters.
Of course, it's easy to implement that constraint (e.g.: in the addInterviewPlan method of a cluster, I'd check if the cluster has a parent or no).
But..., for some reason... I think this is not a good DDD design. That constraint sounds too technical; it doesn't go naturally in a normal domain conversation.
My question: am I over-interpreting DDD "language-fluidity/naturalness requirement"? or... am I missing a concept? I mean, should I invent another domain model, something, that can be a child of cluster and have associated interviewPlan?
Thanks,
Raka
Other related: http://git.net/ml/programming.domain-driven-design/2006-06/msg00028.html
I don't think it is too tehnical. Domain experts knows basic math like sum and in this case they even create that tule.
Tehnical invariants imply tehnical things like tables, indexes, columns, rows, IDs, functions etc.
I have a problem with my UML diagram and I'll be happy if you help me. I have relationships like
Object A (1)<>----(0..*) Object B
Object B (1)<>----(0..*) Object A
and I'd like to unite them. How can I do it? Thanks a lot.
Can you please define the term "unite them"? What exactly would you like to achive? An example could probably help.
Meanwhile, I can try to guess and give you two possible solutions. Maybe they help you to rephrase your question or even to find the solution:
In the Solution 1, I've just made a single relationship that describes both of yours. This can be used if there is only a single and clear criterion of the linkage between the objects. A typical n..m relationship. Objects A will each hold a collection of related objects B and vice versa.
For example a Person (A on the diagram) can join several Clubs (B) and a Club can have several members - there is only one logical relation behind this situation - membership.
Solution 2 is where there are actually 2 different ways to relate between those elements, each one 1..n. So, A holds a collection of Bs and B holds collection of As, but they are unrelated.
Extending the same example - a Person (A) can join only 1 Club (B) and a Club can have many members and hold their reference (col_a on the diagram). In the same time, a Club can have only 1 owner, and a Person can own several Clubs (col_b). Here we have two different logical relations - membership and ownership.
Of course, other multiplicities and navigabilities are possible, this is just an example to give you an idea.
Does one of these situations sound like yours?
UPDATE (after the 1st comment):
So, here is the updated solution 1:
This is an aggregation used here, and this is more a Group-member relationship. It suits perfectly the description of my first solution up there. Members (B) can be "shared" between the Groups (A) and Gruop does not have any special control over their lifetime.
The real Whole-part relationship would employ composition instead of aggregation (visually depicted with a black diamond, instead of a white one). Its semantics it that Whole object has a full control over the life of the contained objects (parts). In consequence, the Parts cannot be shared between several Wholes and must be destroyed if the Whole itself is destroyed.
Now you just need to find out which situation describes your problem the best, pick-up on of this solutions and eventually fine tune the multiplicities.
Here is a way you could represent this scenario in UML.
One server can contain 0 or many Functions (ie. aggregate relationship).
Each function must belong to one server. Or if it is a distributed function then it can belong to many servers.
I have read many about how to configure many to many realtionships with EF Code First and fluent configuration. But I couldn't understand why I should create an extra entity for the junction table. Lets assume that I have the following entities:
Department
----------
Id
Name
Material
----------
Id
Name
Now I want to keep records of materials for each department. So I need
DepartmentMaterial
-------------------
DepartmentId
MaterialId
Quantity
What I have read so far I need 3 entities: Department, Material and DepartmentMaterial. So actually I am mapping each table to a corresponding entity which was not I intended to do when I started to learn about DDD. I assumed that EF is going to map that junction table automatically and also queries about material quantities can be done over Department.
Hence, is it possible in EF Code First to configure fluently such a relation without an extra entity?
The junction table can stay out of the conceptual model (class model) if it's only got two foreign keys (DepartmentId, MaterialId). You want to record some data about the association. That's OK, the quantity belongs there. A department has quantity x of material y. Saying that a department has a quantity is meaningless.
This is not against DDD principles. The association class is a first-class citizen in the class model. It could even have its own behavior (like limiting quantities for certain department/material combinations).
This means that your model will not contain a many-to-many association but Department 1-n DepartmentMaterial n-1 Material. And you'll have to query materials of departments through the junction table. This is a very common situation. I hardly ever see pure junction tables in real life. They're collector's items.
Example query:
var query = from d in db.Departments
from dm in d.DepartmentMaterials
select new { Department = d, Materials = dm.Select(x => x.Material)};
I have a Proffesor table in a database. I would like to create an UML diagram for the code-behind part.
The class structure would be:
- a Proffesor class that maps the information from the database table (id, first name, etc)
- a ProffesorDAL class which connects to the DB and queries it in order to add,remove,update Proffesor instances
- 3 forms which add/delete/update proffesors, by accesing the ProffesorDAL class
I thought that the forms-ProffesorDAL relationship is a composition relationship. Is this correct?
How about the ProffesorDAL-Proffesor relationship, could it be aggregation or is it just association? What's the best UML relationship for the forms-Proffesor relationship?
Thanks!
I'd start by assuming association and from there to analyse and design if there should be a stronger relation between the two.
My question goes "Does it own it". Example I'd say a Car owns 4 wheels (among a long list of other items).
In my standard design I have a BLL between my UI and DAL. I start by assuming a loose association between my three, later I reach the conclusion that the BLL and DAL are somewhat closely connected and could benefit from a strong tie.
As for the Professor class, I assume this to be a Model class. Model classes I only have a loose connection / knowledge to - meaning they appears only as parameters (association). My DALs do not have a strong connection with my Model classes (aggregation). They are but Message bringers, complex ints and bools.
The UML Aggregation relationship is almost worthless - it creates far more confusion than value. It has only one useful property, namely that if used in a recursive relationship, the resulting object structure is acyclic.
It's really not worth getting hung up about. My advice would be to use a simple binary association and concentrate on getting the cardinality right. That's a lot more useful and valuable.
hth.