title: DDD Composing Multiple Bounded Contexts
body: <p>I would like your advices about bounded contexts integration.
  I have a usecase which put me in a corner :</p>
  
  <ul>
  <li>I have a bounded context for <code>Contract</code> 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, ...).</li>
  <li>I have another bounded context for <code>Budget</code>. 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 <strong>integrate a yearly contract financial component</strong>. 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.</li>
  </ul>
  
  <p>It is this last part I struggle with. Each bounded context is a dedicated application. In the <code>budget</code> 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, ...). </p>
  
  <p>What am I thinking :</p>
  
  <ul>
  <li>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 <code>budget context</code>. 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.</li>
  <li>querying budget and for each line query a <code>contract</code> service that will return the data needed. That keep each context autonomous but I need to make lots of database requests to enrich the <code>budget details line</code> objects.</li>
  <li>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 <code>contract</code> structure without rebuilding the budget application. I don't have a programmatic contract between the contexts.</li>
  </ul>
  
  <p>My question is :</p>
  
  <p>How can I build this UI screen that need data from the <code>budget context</code> and each details line need data from the <code>contract context</code> ? </p>
  
  <p>Side Notes : </p>
  
  <ul>
  <li>Perhaps the contexts identification and perimetre are wrong from the start (it is a legacy design).</li>
  <li>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 ?).</li>
  <li>I failed to see how to integrate these contexts (I need to re-read shared kernel, ustream / downstream etc).</li>
  </ul>