1

I'm implementing a college system, and I'm trying to use DDD. I'm also reading the blue book. The basics entities of the system are Institution, Courses, Professors and Students. This system will allow a lot of Institutions, each having its courses, students and professors.

Reading about aggregates, all entities fits inside the aggregate Institution, because doesn't exists courses without Institution, the same for students and professors. Am I right thinking in that way?

In some place the professors will access the courses that they teach. Using this approach, should I always access the courses through Institution? This implementation seems strange to me, so I ask myself if Professor, as Students should be their own AR and have their Repository.

Rodrigo Otavio
  • 77
  • 7
  • 2
    Following this mentality, you will end up with a single aggregate root: Application. Forget all about "x cannot exist without y", it's an horrible way of finding roots. Instead, look at commands and business rules and find out which data is needed to process a command and check those rules. – plalx Sep 21 '15 at 20:35
  • Yes, that's exactly what I was afraid of: end up with a single aggregate root. But to try another approach, I was afraid of breaking the business' rules. But now I see that's it's a wrong way of look at the DDD. Thanks for your comment. – Rodrigo Otavio Sep 21 '15 at 20:54
  • Rules will be protected as long as data used to process a command are in a single AR. – plalx Sep 21 '15 at 23:36

4 Answers4

3

Even though you have accepted an answer I am adding this anyway since a comment is too short.

This whole aggregate root business trips up just about everyone when starting out with DDD. I know, since I have been there myself :)

As mentioned, a domain expert may be helpful in some cases but keep in mind that ownership does not imply containment. An Order typically belongs to a Customer but the Customer is not the AR for an Order since an Order can exist without a Customer. You may think: "But wait, that isn't really true!". This is where is comes down to rules. When I walk into a clothing store I can purchase a pair of shoes. I am a customer but they have no record of me other than a receipt I can produce. I am a cash customer. Perhaps my particular brand of shoe is not in stock but I can still order it. They will contact me once it arrives and that will probably be that and I'll in all likelihood still not be registered in any computer system. However, that same store is registered as a Customer with their supplier.

So why this long-winded story? Well, if it is possible to have an Entity stand alone with only a Value Object representing the owner then it is probably going to be an AR. I can include some basic customer information in a CustomerDetails value object in an Order? So the Order can be an AR.

No let's take a look at an OrderLine. Can I include some basic OrderDetails information on an OrderLine? This feels odd since a number of order lines constitute an Order. So it isn't quite as natural.

In the same way a GrapeBunch has to have a GrapeStem and a collection of GrapeBerry objects.

This seems to imply that if anything can be regarded as optional it may indicate that the related instance is an AR. If, however, a related instance is required then it is part of the AR.

These ideas are very broad but may serve as guidelines to consider your structure.

One more thing to remember is that an AR should not be instanced in another AR. Rather use the Id or a Value Object representing the relationship.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • So good had to upvote, good points on identity and grape example – morleyc Sep 22 '15 at 04:59
  • Thank you, it's a great answer. So, let's consider a professor and a course. Professor is an AR. But professor it's not an optional value of course, every course needs a professor. But professor can't be part of the AR course, because a professor stands alone. So in that way, the entity Course will have an id or value object representing a Professor. Is that right? So, even then, should Entity Professor has a collection of courses? Or should it be assigned to a ProfessorRepository? Because this is an information that is very required to list the courses of the professor in a Professor area. – Rodrigo Otavio Sep 22 '15 at 11:43
  • In the `Professor` and `Course` example the same rule applies so `Professor` could have a collection of `CourseTaught` VOs that perhaps contain a `Name` and `Id`. The fact that you have a rule stating that a professor *has* to teach at least one course does not mean that the course will necessarily exist as an entity within the professor object since professor does not have its existence tied to a course. A order, for example, has no meaning without at least one order item. These things are tricky so it is near impossible to define concrete rules to establish ARs. – Eben Roux Sep 22 '15 at 12:50
2

I think you're missing some transactional analysis - what typically changes together as part of the same business transaction, and how frequently ? One big aggregate is not necessarily a problem if only 2 users collaborate on it with only a few changes per day, but with dozens of concurrent modifications it could become a contention point.

Besides the data inventory and data structuration aspect of the problem, you want to have an idea of how the system will be used to make educated aggregate design decisions.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
1

Something that might help you to separate those entities into different aggregate roots is to ask you: Which one of those must be used together? This is usually helpful as a first coarse filter.

So, for example, to add a student to a course, you don't need the Institution?

In your example about a professor accessing the courses he teaches. Can he access them by providing his professor id rather than the professor entity? I he provides the professor id, then the entities won't be associated by a reference but by an id.

Lots of this concepts have evolved a lot since the blue book was written 12 years ago. Even though the blue book is a really good book, I suggest you to also read the red book (Implementing Domain-Driven Design by Vaughn Vernon). This book has a more practical approach to DDD and shows more modern approaches, such as CQRS and Event Sourcing.

Augusto
  • 28,839
  • 5
  • 58
  • 88
  • Thanks for answer. I really want to read this book, but the deadline is close. To add a student to a course, I need only the id of the institution. And I can find the courses of a professor just using the id, not a whole instance. So, in this case, could be both professor and student an AR? – Rodrigo Otavio Sep 21 '15 at 20:44
  • Yes, that's the idea! – Augusto Sep 21 '15 at 21:00
0

A professor and a student can exist in their own right, indeed they may associate themselves with institutions. An institution exists in its own right. A course may exist in its own right (what if the same course is offered at more that one institution, are they the same?)... The domain expert would best advise on that (infact they should advise and guide the entire design).

If you make an aggregate too big you will run in to concurrency issues that can avoided if you find the right model.

Some PDFs I recommend reading are here:

http://dddcommunity.org/library/vernon_2011/

morleyc
  • 2,169
  • 10
  • 48
  • 108
  • Thanks for answer. I was just now reading these pdf's, and they are very helpful. It's exactly about big aggregates. But about the courses, they will exists for more than one institution, but as instances. The institution will be able to change the name for example of the course, without changing the original product. In that case, the instance of course exists only for one institution. – Rodrigo Otavio Sep 21 '15 at 20:39
  • A question: in the part 1, he uses the product_id as a Value Object. It is a good approach for my case? – Rodrigo Otavio Sep 21 '15 at 20:48
  • Yes an identity is a value object that once created cannot be modified. I tend to create classes for identities as opposed to int, string etc as it helps identify explicitly when reading the code what we are referring to – morleyc Sep 22 '15 at 07:32