DDD: one bounded context or two?

Question

Suppose I've built a system for my client that allow gamblers to maintain a portfolio of bets and track their gains/losses over time. This system supports a lot of complex domain logic - bets on different sports, rolling over wins to other bets etc.

Next my client wants to support the idea of tipsters. The tipsters do not actually gamble, instead they create "tip sheets", which are their tips on what bets to place. The tip sheets can be of different kinds - some can include tips on any bettable event, others only offer tips on horse racing, and so on. My client wants the system to track the performance of tipsters in the same way as it tracks the performance of gamblers, with the additional twist of being able to compare performance within and across different kinds of tipster (e.g. who is the best horse racing tipster? do they in general perform better than football tipsters?)

Now, the domain language is completely different between gamblers and tipsters, and there is the additional categorisation of tip sheets that doesn't exist for gamblers' portfolios. This suggests these are separate bounded contexts. However, there is a lot of shared logic as they both track performance over time.

So my questions are:

1. Are these really separate bounded contexts? I'm wary of adding categorisation to the gamblers context (feels like a slippery slope).
2. If they are distinct contexts, should I:
   • Share performance tracking logic between them (i.e. share DLLs, jars etc)? This creates a tight implementation coupling between the contexts which feels wrong.
   • Leave the performance tracking logic in the gambling bounded context, place the categorisation logic in the tipster bounder context, and have it ask the gambling context to track performance? In this case, it seems like the tipster context will send commands to the gambling context, which again feels wrong (I'm more comfortable with events).
   • Do something else...some kind of composition layer that communicates and correlates between both contexts?

Clarification

A gambler's portfolio and a tipster's tip sheet are almost identical - the only difference is that the tip sheet can be categorised (e.g. horse racing, football etc).

Performance tracking is about measuring the profit/loss of the portfolio/tip sheet.

Answer 1

I'd probably agree with Mike that Performance Tracking sounds like a Bounded Context on his own. This looks like the more evident boundary.

Betters and Tipsters might act on different aggregates of the same bounded context or different bounded contexts. I'd be inclined to choose the latter, according to what you say about the language, and about project evolution.

Answer 2

1. If you see two clearly separate models, with only technical overlap, then I would agree that you have two BCs. However, be aware that having multiple BCs, especially when they need to communicate, can be a bit "expensive". It is much "cheaper" to employ modules, which is why you should not take the decision to have multiple BCs lightly.

2. The blue book, Part 4 (Strategic Design), Chapter 15 (Distillation), introduces the notion of a generic subdomain which fit nicely into your scenario. Performance calculations can be regarded as a generic subdomain because while they are essential to the overall functioning of your model, they can be isolated into a library which can be used by two BCs. This is a pattern for distilling your model and keeping technical concerns abstracted away. You don't need to implement complex messaging or RPC communication between BCs, just use a shared library with intention-revealing interfaces.

Answer 3

It's clearly a case for (at least) 2 bounded contexts (BC), the fact that they have a different domain language is the biggest clue.

If I undertand correctly, the performance tracking is a domain concept and probably it should be a BC itself. You can define interfaces for common tracking and particular tracking (for tipsters) - in a common interfaces kind of project - which will be implemented by the entities from other BCs. So the PerformanceTracking BC will not care about concrete gamblers or tipsters and the other BCs won't be coupled to a specific performance tracker.

And yes , you will need to synch the BCs and the Domain Events are exactly for that purpose. It's not exactly simple, but if done carefully it's not that complicated and you get the great benefit of loosely coupled code.

Answer 4

I do think that they are two different contexts and you think so too, right?

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

You could of course create adapters in between which doesn't belong in any of those jars/dlls. I.e. something that subscribes on the domain events in context1, adapt the information and then call stuff in context2. In that way you get 100% transparency between the contexts.