1

My software is a kind of social network where members can, among other features, schedule some meetings between them.

I chose to emerge those three bounded contexts (DDD):

  • IdentityAndAccessContext, basically dealing with user authentication/authorisation.
  • SocialContext, dealing with Members and all social information about them; their interests etc., akin a classical social network.
  • MeetingsContext, dealing with meetings between some members. We're talking about translated Value Objects as Creators/Attendees/Participants etc.

Basically, in the MeetingsContext, the meeting's creation use case demands a list of members (in order to invite some of them), basically through a Web form where user selects some members presenting some interesting but light social information.

As you may figure out, SocialContext is clearly the master of members data in a social way.

Should I create a kind of Open Host Service in the SocialContext returning some relevant members data for the use case?

It would be consumed by MeetingsContext directly (REST protocol), maybe through an Anti-Corruption Layer if needed.

Or should I rather cache or even maybe duplicate relevant member's data in the MeetingsContext to improve it's self-contained aspect?

With the caching solution, the cache would be sync in an eventual consistency manner.

What is a good practice in this case?

Mik378
  • 21,881
  • 15
  • 82
  • 180
  • 1
    fwiw, `IdentityAndAccessContext` isn't a bounded context or domain concept at all. Identity and access (authorization, authentication, acl etc.) are application concerns, not domain concerns are to be handled at application level, not on domain level – Tseng Sep 05 '17 at 13:10
  • @Tseng Check out the book "Implementing Domain-Driven Design" by Vaughn Vernon. You will see that IdentityAndAccessContext is a bounded context he takes along. – Mik378 Sep 05 '17 at 13:19
  • 2
    Authentication (=Identity) is almost never a part of a domain and hence not business logic (unless your domain is some kind of security company, which manages security access for other companies, i.e. creating and issuing physical tokens to some companies employees). Authentication/Identity usually don't play a role in a business process and it's good this way, as authentication and identity may change with your infrastructure. It's like the NSA. Your identity is only checked at the gates (application). Once you're inside (domain), you're free to walk around with your name plate (user id) – Tseng Sep 05 '17 at 13:59
  • In this context, you need identification only to confirm that "logged in user is the user from the `SocialContext` with the id `xyz`" and this is clearly a responsibility of the application, **not** the domain – Tseng Sep 05 '17 at 13:59
  • @Tseng You can block one person, you can create an account on behalf of another person, you can change defined roles of one or several persons according to amount of connections in a month for instance etc.. I&A context can definitly have its own domain with its own complexity. – Mik378 Sep 06 '17 at 07:11
  • 2
    You are mixing person with identity/accounts here. In your `SocialContext` `Person` or `Emplyoee` are the domain entities/aggregates. You can't "Block an emplyoee", this is nowhere a part of a business process. You can just assign (to a group/tenant/company/etc)/remove/delete it. Identity is something completely different. Identity (in simplest case) may only consists of a username, a login and an associated id (i.e. person id), so you can tell: "S/he has confirmed that s/he is **this** person". Nothing more, no business logic involved, its all application concern. – Tseng Sep 06 '17 at 07:21
  • @Tseng Yes yes it was just to basically explain my point. The real term is User, sorry. – Mik378 Sep 06 '17 at 07:22
  • But Login, password verification, resetting of password, changing user name (this has no effect on the `Person` or `Emplyoee` entities at all) etc. All of these **are not business processes**, hence: not domain logic. They are all rather specific to the application. – Tseng Sep 06 '17 at 07:22
  • @Tseng How would you explain that Vaughn Vernon consider it as a BC? – Mik378 Sep 06 '17 at 07:23
  • https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess – Mik378 Sep 06 '17 at 07:25
  • Obviously (from the github repo), he mixed up `Person` and `User` into the same context as for why, only he can tell. Simplification for the book/example? `Person` or `Employee` is okay as domain entity, as it describe an entity which is part of a business process. `User` isn't really. Personally I'd move `User*`, `AuthenticationService` and `PasswordService` out of it as well as the authentication. – Tseng Sep 06 '17 at 07:36
  • Domain may just have a `Someinterface.canAccess(personId, "someClaimOrPermission")` and have the application implement that interface with this method. So domain would be unaware of concepts like claims. Roles may be okay, depending on the problem domain (i.e. roles are common in business process, such as Manager, Support, etc.). But in the implementation detail (on application layer) a role may be represented as a bag of claims. Domain wouldn't need to know about this infrastructure detail – Tseng Sep 06 '17 at 07:37
  • No, clearly he does not mix anything. Person is a kind of user profile( basic data like firstname), but unaware of business domain concerns. – Mik378 Sep 06 '17 at 07:37
  • I agree, that s why I use some gateways to deal with I&A context from other contexts like your "canAccess". But I truly believe that I&A is a BC. – Mik378 Sep 06 '17 at 07:39
  • Read the book IDDD, you will see that it s well detailed and not "simple for an example in a book" – Mik378 Sep 06 '17 at 07:40
  • Well its your opinion and I'm unlikely going to change it,just offered my point of view.Just a last thing to write (its getting lengthily): You should think about it (rather than being dogmatic about whats in a book): In which well defined (real world) domain context did you ever hear the terms "user name" and "password".I haven't.They aren't part of the business process. The business process is often the one how the business operates,even if they do not have a software yet helping them with their process and the terms "user" and "password" never appear there,you just have persons/employees :) – Tseng Sep 06 '17 at 07:46
  • Bounded context is not just about isolating Business domain things. It's about conserving ubiquitous language. I never heard about "username/password" in a business domain too; it's just a matter of technical things. But to keep ubiquitous language and because it can come with complex authentication/authorization rules, it should be model as a distinct BC. See the bottom of this answer: https://stackoverflow.com/a/23485141/985949 – Mik378 Sep 06 '17 at 07:55

2 Answers2

1

It depends but I would use an Anti Corruption Layer (ACL) in order to separate the three Bounded Contexts.

Regarding the use of a cache: you could use that; this is orthogonal to ACL. The ACL could be decorated by a cache to speed things up or it could itself be a local persistence that keeps a local copy of the remote data.

Regarding eventual consistency: of course you will have eventual consistency between bounded contexts, your design must take that into consideration.

Basically, in the MeetingsContext, the meeting's creation use case demands a list of members (in order to invite some of them), basically through a Web form where user selects some members presenting some interesting but light social information.

The UI could be a special case that combines data from more bounded contexts; don't let the UI blur the clear separation between bounded contexts.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • You said that: "don't let the UI blur the clear separation between bounded contexts." May you rephrase this sentence to be sure I'm clearly grabbing your point? – Mik378 Sep 04 '17 at 12:50
  • 1
    From my experience, when doing the UI, more than one bounded contexts are used to build a particular view and in that point models tend to influence each-other. The UI is behaving like an Anti Corruption Layer that translates models from the software to models from the real world. – Constantin Galbenu Sep 04 '17 at 13:57
  • 1
    @ConstantinGalbenu UI can be a context in its own. It is not an ACL most of the time. It can be a gateway, an aggregator, or each BC can deliver it's own UI. – Alexey Zimarev Sep 04 '17 at 18:00
  • Thanks @ConstantinGalbenu for your answer, very clear. – Mik378 Sep 04 '17 at 18:31
1

Composite UI is a good choice in these situations. Your meeting contexts does not need to know anything more than member id and perhaps some information about their communication preferences in order to establish a meeting.

Composing a list of participants does not require the meeting context involvement. This UI element can very well come from the social context UI and then send the list of participant ids to the meeting context, when selection is complete.

The general rule is to avoid data transmission between contexts just in sake of showing some stuff on the screen. The responsible context should be doing that.

Here are some references:

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • I like your idea about only dealing with memberId in the meetingscontext. Regarding the meeting's creator that is mandatory to any meeting, do you find appropriate to duplicate his firstName and his lastName data (light data) from socialContext so that the main meeting query could be as simple as "select * from meetings"? And regarding participants, that could involve an acceptable loading delay, thus making an additional query to the social context from the UI is possible. – Mik378 Sep 04 '17 at 15:25
  • 1
    You can have a deal of data duplication of course, especially if you don't care about updates. In your case this seems reasonable. I updated my answer with the link to some articles that discuss this approach. – Alexey Zimarev Sep 04 '17 at 18:01
  • Thanks for the references Alexey, very useful :) – Mik378 Sep 04 '17 at 18:29