2

As the question states, is this bad practice? I have a User aggregate root in the bounded context of Identity for authenticating the user. In this bounded contexts I have fields for the User related to identification of the User e.g. email, salted pw and so on.

I also have a generic subdomain for handling notifications. In this context a User is a Notificant. In this context, the Notificant has fields for e.g. the number of unread notifications, lastRead etc.

Is it good to reuse the User id in this case, as I know there is a 1-to-1 correspondence between a User and Notificant? Or should I have a field in the Notificant root referencing the User? It feels redundant, because then I have to make a lookup to map between them when I know their relationship is symmetric.

Improve this question
1
  • I stumbled upon this post which seems to be referring to the same question, but it seems the discussion never came to a conclusion. Any ideas?
    – udnes99
    Commented Jan 11, 2021 at 21:42

1 Answer 1

Reset to default
5

No, don’t reuse aggregate root keys for identifying different objects in different contexts !

Why?

  • Because a Notificant is not a User. Maybe today, mostly users get notified. But tomorrow you may have to notify third parties who are not using the system, or even automatic monitoring systems.
  • Because it’s another bounded context, and bounded contexts may evolve independently. Maybe today User and Notificant share the same granularity and may be directly related one to one. But who knows about tomorrow? So you need to carefully think about how they should be related.
Improve this answer
4
  • Thank you for clarifying--that makes perfect sense.
    – udnes99
    Commented Jan 11, 2021 at 22:26
  • 1
    One question, though. How would I map in the best way between the contexts? I would assume that the User should hold a reference to the Notificant as opposted to the opposite. Otherwise I would have to extend the fields for the Notificant for each new system that should use it. But at the same time, this would cause a coupling from User to Notification which is bad, imo--the User in the context of Identity should not be concerned with Notifications.
    – udnes99
    Commented Jan 11, 2021 at 22:30
  • 1
    @muffe exactly: identity should not be concerned with notifications. You could maintain two different sets of data but that’s not ideal either, if both needs to be kept in sunc. You could have Notificant as abstract class with a concrete class for user-notificants that would refer to Users. There are a range of strategies to manage this depending on how the teams managing each bounded context cooperate (e.g. shared kernel vs customer/supplier design vs conformance vs anti-corruption layer or open-host service). But it’s too broad for a couple of comments ;-)
    – Christophe
    Commented Jan 11, 2021 at 22:56
  • Thank you, this leads me onto the right path :)
    – udnes99
    Commented Jan 11, 2021 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.