DDD: one limited context or two?

Question

Suppose I created a system for my client that allows players to maintain a portfolio of bets and track their profits / losses over time. This system supports a lot of complex domain logic - bets on various sports, rolling winnings to other bets, etc.

Then my client wants to support the idea of ​​hints. Mentors do not actually gamble; instead, create “tips” that are tips on which bets to place. The help sheets can be of different types - some may include tips on any event with a win, others - only tips on racing, etc. My client wants the system to track the performance of prompts in the same way that it tracks the performance of players, with an additional turning point that allows them to compare performance inside and between different types of tips (for example, who is the best horse?), Do they work better than football coaches? )

Now the language of the domain is completely different between players and tips, and there is an additional categorization of tips sheets that do not exist for player portfolios. This suggests that these are separate, limited contexts. However, there is a lot of common logic as they track performance over time.

So my questions are:

• Are these really separate limited contexts? I carefully add categorization to the context of the players (feels like a slippery slope).
• If they represent different contexts, I should:
  • Separate the logic for tracking performance between them (i.e. share DLLs, banks, etc.)? This creates a tight realization of the connection between contexts that feel wrong.
  • Leave the performance tracking logic in a limited gambling context, put the categorization logic in the prompt context context, and ask the gambling context to track performance? In this case, it seems that the hint context will send teams to the gambling context, which again feels wrong (I'm more comfortable with the events).
  • Do something else ... some kind of composite layer that connects and correlates between both contexts?

Explanation

The portfolio of players and the sheet of the overturner are almost identical - the only difference is that the tip sheet can be classified (for example, horse racing, football, etc.).

Performance Tracking is a measurement of portfolio / sheet gain / loss.

Answer 1

I would probably agree with Mike that Performance Tracking sounds like a limited context in itself. It looks like a more obvious border.

Betters and Tipsters can act on different aggregates of the same bounded context or different bounded contexts. I would be inclined to choose the latter, in accordance with what you say about the language, and about the development of the project.

Answer 2

• If you see two clearly separate models, only with technical coincidence, then I would agree that you have two BC. However, keep in mind that having multiple BCs, especially when they need to communicate, can be a bit "expensive." It is much “cheaper” to use modules, so you should not decide that several BCs are frivolous.

• The Blue Book Part 4 (Strategic Design), Chapter 15 (Distillation), introduces the concept of a common subdomain that fits well with your scenario. Performance calculations can be considered as a common subdomain, because although they are necessary for the overall functioning of your model, they can be isolated in a library that can be used by two BCs. This is a sample to distill your model and troubleshoot technical issues. You do not need to implement complex messaging or RPC communication between BCs, just use a common library with target interfaces.

Answer 3

This is obviously the case for (at least) 2 restricted contexts (BC), the fact that they have a different domain language is the biggest key.

If I'm sure performance tracking is a domain concept and probably it should be BC itself. You can define interfaces for general tracking and specific tracking (for those surveyed) - in a project of the type of common interfaces that will be implemented by objects from other BCs. Thus, PerformanceTracking BC will not care about specific players or hints, and other BCs will not be tied to a specific performance tracker.

And yes, you will need to synchronize BC, and domain events - just for this purpose. It is not quite simple, but if done carefully, it is not so complicated, and you get great benefit from loosely coupled code.

Answer 4

I think these are two different contexts, and you think so too, right?

I personally used domain events from the gambling context to generate performance tracking information. The code is still loosely coupled (since the logic depends only on domain events).

Of course, you can create adapters between them that do not belong to any of these jars / dlls. That is, that subscribes to domain events in context1, adapts the information, and then calls the material in context2. This way you get 100% transparency between contexts.