title: Scaling Service Boundary (SOA)
body: <p>I am new learner in SOA ( Service Oriented Architecture ) I have one question for below scenario:</p>
  
  <p>In a company (Mycompany), Sales Team is there ( which is a technical authority for business capability –here sales is the business capability). That company decided to create 2 products say Mycompany.Photos.com and Mycompany.Grocery.com. For both websites they need sales capability i.e. order acceptance capability. </p>
  
  <p>Hence Sales team has to work for both websites. Because, both website needs sales capability.</p>
  
  <p><strong>Now the question is should sales team create 2 different databases for each websites and 2 different endpoints also ?</strong></p>
  
  <p>for example:</p>
  
  <p>If Sales team initially had one queue "Mycompany.Sales.Endpoint" and it receives CreateOrderCommand. It handles CreateOrderCommand, creates order in sales DB and publishes OrderAcceptedEvent. When they were supporting just one website. If they start supporting both website with same endpoint then how would Sales differentiate weather this order is for Mycompany.Grocery.com or Mycompany.Photos ? Should we split Mycompany.Sales.Endpoint into 2 ? should sales team has to be aware of Photo website orders and Grocery Website orders ?</p>
  
  <p>One answer I can think of is: </p>
  
  <ol>
  <li>Sales team can create 2 different databases each for Mycompany.Grocery.com 
  and Mycompany.Photos.com  </li>
  <li>Deploy 2 different Business Components (BC) for each websites.</li>
  <li><p>Sales will have 2 Endpoints say "Mycompany.Grocery.Sales.Endpoint"
  for Mycompany.Grocery.com BusinessComponent and  "Mycompany.Photos.Sales.Endpoint" for MycompanyPhotos.</p>
  
  <p><strong>Even though they are under same Sales Bounded context, can it have 2 Business
  Components (BCs) ? Am I correct, Is this the way we scale sales team will support both products for the sales capability ?</strong></p></li>
  </ol>
  
  <p>I am sorry for the long message. I could not find any shortcut way to explain this.</p>