How to Combine Data From Different Bounded Context in DDD

Question

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?

Quadruped

Answer 1

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.

Runofthemine

Answer 2

I think you are in the wrong way. Something that is related to Authentication should not to be in the domain layer. Student and Teacher are entity, but Account in AuthService is not entity. As far as I see, you would like to add a new Student or Teacher by using some information that come from Account, but for doing that you should pass this information by fetching User Account info and pass them to Student or Teacher class to instantiate a new object.

For your second question, depends on our business, you could have same properties. DDD just emphasize that you should use ubiquitous language for naming entities and methods and it doesn't matter you use same properties.

Gamez

Authentication is purely CRUD – Quadruped

Yes I know, but every thing that has CRUD is not entity. Your business is different. Are you writing Authentication service? I don't think so. That is just a tools for authenticating that usually has been applied in infrastructure layer. – Gamez

@AliSoltani I think you are confusing a domain layer with core domain. – Runofthemine

While Authentication Service may be primarily behavior, the backing data is stored "somewhere." Account is going to be an entity, with Student and Teacher as different roles. Student and Teacher can simply be DTOs at the end of the day; there is more than one way to model this. I think what @AliSoltani is referring to in his mind is the aspect of Authentication during API calls. That is an Application Layer concern and does not belong in the Domain. – Distrait

@SubhashBhushan True, the authentication may not be the intent of the current domain, but it can be the intent of another, designated authentication-related domain. That's exactly what my comment meant - authentication may belong to the domain layer, but probably not to the core domain, assuming the authentication is not the core of the business we are looking at (maybe it is). – Runofthemine

@Runofthemine Agree 100% – Distrait