Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to Combine Data From Different Bounded Context in DDD

Example:

I have two bounded contexts Exams and Courses. The Exams context has a Student entity that has information about the students to take an exam. And the Courses context has a teachers entity that contains information about the teacher teaching a course.

I also have an AuthService (purely CRUD), that is used for Authentication and Authorisation of users. The AuthService has an Accounts entity, which contains information like accounts user's name, address, phone number e.t.c.

Bringing them all together, The Student and the Teacher both have Accounts hence their information is already available.

I have a couple of question about this.

  1. Is it anti-pattern in DDD to store the AccountId in the Student and Teachers Entity? If it isn't anti-pattern at what point is it ok to collect students account information using the AccountId, In repository or in the API controller, or should we use RPC/API calls.
  2. Is it okay to copy the details needed from the Account entity into a Student or Teacher Entity?
like image 781
James Okpe George Avatar asked May 28 '19 12:05

James Okpe George


Video Answer


1 Answers

I assume the AuthService is in its designated bounded context for authentication and, Accounts is in that same bounded context too.

Here are my answers:

Is it anti-pattern in DDD to store the AccountId in the Student and Teachers Entity?

You can store AccountId in Student and Teachers entities. This is not an anti-pattern but rather opposite - this is how different aggregates refer to each other, by keeping the Id of the other aggregates.

If it isn't anti-pattern at what point is it ok to collect students account information using the AccountId, In repository or in the API controller, or should we use RPC/API calls.

I don't understand which repository you mean exactly, for Account, Student, or Teacher? Each aggregate root has its own repository and that repository is responsible for storing those aggregates only. It does not know or query other aggregates. If you need to query other bounded contexts, do that from the application layer - if the operation that does this is not a domain concern. If it's a domain concern, then do this in the domain layer by representing another bounded context as a domain service (interface). RPC/API is an implementation detail for the inter-bonded context calls and you can use either way to query another bounded context, as long as the implementation details don't leak into the domain layers.

Is it okay to copy the details needed from the Account entity into a Student or Teacher Entity?

That is also okay. You do that to achieve higher availability for the price of eventual consistency. In such a case, the bounded context/entity that holds information from another one acknowledges that the copy of the data can go stale but that is acceptable by the business terms.

Let me know if any questions. I am a long-run DDD practitioner.

like image 99
Tengiz Avatar answered Oct 05 '22 23:10

Tengiz