4

I would like your advices about bounded contexts integration. I have a usecase which put me in a corner :

  • I have a bounded context for Contract management. I can add parties (various external organizations for example) to a contract. Select for each party their investment / contribution (ex: 10% of the total). SO contract management is two-fold : one is administrative (add party, manage multiples dates, ...) the other one is financial (plan their contributions that span multiple years, check contributions consumption, ...).
  • I have another bounded context for Budget. This context is responsible for expenses management at the organisation level. Example: a service A will have 1000 € of expense capacity. We can plan a budget and after that each organisation party can consume, buying stuff, their part. In order to build a budget, the user in charge of the enterprise budget can allocate money directly or integrate a yearly contract financial component. When we integrate a contract part inside the budget we froze the data inside the budget, i.e we copy the monetary data from one database table inside another one (adding some audit informations). We have a single database.

It is this last part I struggle with. Each bounded context is a dedicated application. In the budget application, after a contract part has been integrated inside the current budget, I need to display the budget details lines. Unfortunately in the budget tables I have only the money data and not some basic info about the contract (object, reference, ...).

What am I thinking :

  • sometimes is not bad to duplicate data between bounded contexts. I froze the money part of a contract. I can also freeze / duplicate the object and reference of the contract. Then the querying will only take place inside the budget context. But what is problematic here is the data duplication. Today I need object /refrerence and if tomorrow I need more fields ... I will need domain events management to keep the data between contract / budget in sync.
  • querying budget and for each line query a contract service that will return the data needed. That keep each context autonomous but I need to make lots of database requests to enrich the budget details line objects.
  • with only one join at the database level we can make this work. What about coupling here ? It is the simple solution and what we are doing today (is it a shared kernel ?). It seems we can't afford to change contract structure without rebuilding the budget application. I don't have a programmatic contract between the contexts.

My question is :

How can I build this UI screen that need data from the budget context and each details line need data from the contract context ?

Side Notes :

  • Perhaps the contexts identification and perimetre are wrong from the start (it is a legacy design).
  • What I would like is to keep the context separate (loose coupling). If we can specify design contracts between the contexts, the maintenance is easier (or not ?).
  • I failed to see how to integrate these contexts (I need to re-read shared kernel, ustream / downstream etc).
jnm2
  • 7,960
  • 5
  • 61
  • 99
Archange
  • 397
  • 5
  • 21
  • This is an additional, distinct bounded context. It has some overlap with the existing bounded contexts, which can easily lead you down the wrong path (merging contexts or putting additional behaviour in a context where it doesn't belong). – MattDavey Feb 22 '15 at 12:51
  • Can I ask you how you will model this new, third context ? (move all domain logic inside it and query it ?). This new context will be `budget` oriented too. It adds complexity. I understand your comment. I will think about it and how this context can emerge. In implementing DDD, Vernon talked about it but provide no example :/ I feel naked ! – Archange Feb 22 '15 at 13:03
  • I expanded my comment into an answer. – MattDavey Feb 22 '15 at 13:24

1 Answers1

1

This is an additional, distinct bounded context. It has some overlap with the existing bounded contexts, which can easily lead you down the wrong path (merging contexts or putting additional behaviour in a context where it doesn't belong).

Sometimes it's OK to have entities in different bounded contexts which are referring to the same logical entity, but which are just providing a different view of that entity for the purposes of a specific scenario (eg in a specific context).

A good example of this is in an e-commerce scenario. In most e-commerce applications you will have the concept of an Order, but there is no global, definitive notion of what an "order" is. In a finance context - the order is simply an invoice. In a fulfilment context - the order is simply a packing list and an address to send the goods to. In a marketing context - the order represents a little piece of intelligence about what the customer is interested in, which can be used for future targeted marketing.

There is a thread of commonality which runs through all of those entities, but you would likely see at least 3 separate Order classes, each one capturing the concept of an order within a context.

And so in your case, you have a bounded context for Contract and a bounded context for Budget. It seems to me that you now have another way of looking at these entities, and specifically the way in which they interact with each other. This is a new view of the entities, a view which can be captured in its own context. This new context will likely have its own Contract and Budget entities, and there will be overlap with the Context and Budget contexts, but there will also be additional relationships and behaviour in there, which wouldn't make sense in those other contexts.

This is a really difficult idea to explain :) I wrote an answer to a similar question some time ago here: DDD - How to design associations between different bounded contexts

MattDavey
  • 8,897
  • 3
  • 31
  • 54
  • Thanks a lot. I thought about it. It reminds me about the Book example used by Evans (a different book class exists and follow the book lifecycle : draft, editing, ...). But in this example I always thought it was a different logical entity (logical in a databse sense : different tables) and that using Domain Events tese entities were keep in sync. When you talked about logical entity, you're talinkg about the same databse table am I right ? – Archange Feb 22 '15 at 13:42
  • @Archange That's a possibility, but the repository should abstract that detail away. Naturally, as we're dealing with a new context, it should have a new repository. In DB terms, you could say this context encapsulates a join between two tables, but we try not to let the DB schema influence our understanding of the domain :) – MattDavey Feb 23 '15 at 04:45
  • I agree with you about the database abstraction. I was thinking about microservcies architecture [Fowler ] and the ability to rebuild a microservice from scratch. As long as its contract with others microservices are honored, everything is fine. But if we build a BC using a new repository that join 2 tables at the database level. Don't we have here a high coupling at the DB level: we can't change the DBstructure (renaming a column) without rebuilding 3 BC. I was hoping to avoid this. Perhaps I'm wrong about this. – Archange Feb 23 '15 at 06:57
  • 1
    @Archange if you encapsulate things into classes at OOP, you will have "coupling" everywhere you call a method on a class, since the callee needs to know the signature. That doesn't mean it's bad to use encapsulation. It just means you have moved from coupling logic to "coupling" interfaces, which is fine because that's what interfaces are for. For BCs, it's ok to share messages or basic DTOs. Neither BC will know what the other BC is using it for. So they are decoupled at a high level, which is what you want. But sure, they rely on each other's interfaces still. – C S Jan 21 '19 at 17:18