8
votes

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?
2

2 Answers

8
votes

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.

-2
votes

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.