CODEWITHSUNDEEP
domain-driven-design
Panos
Panos

Reputation: 55

DDD with entities that contain too much information

I decided to put into practice what I recently learned about DDD, but I got confused about what to do in my scenario. I am very new to this school of thought so pardon my ignorance

Consider the following :

How do you define this model?

My initial thought was that the School is the AR, as classrooms cannot exist without the school and a StudentAttendance cannot exist without a Classroom.

My question is, in order to change a random StudentAttendance Record's NumberOfStudents (let's say that SchoolId 10, Classroom 1 in 1993 had 25 students instead of 30) , do I need to create a valid School first? This would mean that I need to get huge amounts of information to populate all of the other properties that are not necessary for my action. I basically just need the schoolId, the classroomId, the year and the new number.

In the old CRUD world, I would just define a method
UpdateStudentAttenance(int schoolId, int classroomId, int year, int newNumberOfStudents)

Note: According to DDD, I have created the classes with constructors that populate all of the properties, to create and keep them in a valid state (e.g. a School must have a Name, Area, ConstructionYear etc) so I cannot just call new School(id: 5)

Upvotes: 1

Views: 604

Answers (1)

jlvaquero
jlvaquero

Reputation: 8785

You can have several School or Classroom (or any other entity) in your domain. The key here is Bounded Context (BC) segregation. Every BC have its own School with just the properties that matters for this BC. The properties that matters in every BC depends on domain actions and the info you need to acomplish the actions. This rule also apply to VO's and Aggregates.

i.e.:

You define 3 Product entities. One in the Warehouse BC, one in the Marketing BC and one in the Store BC. As Warehouse BC just has domain actions related to inventory, provisioning, transport, etc; the Product entity for Warehouse does not need the Customer Price property.

And not only several same thing (Entity, VO or AG) in different BCs. You can also have same domain concepts (school, classroom, etc) that takes different roles in every BC in which are involved. A school can be a entity in one BC, a aggregate root in another BC and a VO in a third BC. And each one has its own implementation with its own constraits, methods, properties, etc.

The best way to design with DDD is to think about domain actions. All your domian design has to gravitate around domain actions and the info it needs to acomplish these actions.

Also take note that if you do not have a process workflow with a clear intend in your system (i.e. just updating NumberOfStudents to fix a mistake and no collateral effects exist) you do not need DDD, you just need CRUD and it is not wrong to have DDD in some part of the system and CRUD in another part.

This answer can also help in your design: Aggregate or entity without business attributes

Upvotes: 1

Related Questions