0

I currently have two projects within one Visual Studio solution. Each project represents a different aggregate. I need to add a domain service that interacts with the two aggregate roots. Which project should I add it to? Does it matter?

Mike Lenart
  • 767
  • 1
  • 5
  • 19
  • Can you provide an example pls? Feels like your boundaries are wrong. Why would you need such a domain service? – DmitriBodiu Mar 16 '20 at 14:36
  • Say I have an aggregate that is Customer and another one is BankAccount. When I create an account I need to create the Customer aggregate and then the BankAccount aggregate. – Mike Lenart Mar 17 '20 at 00:46
  • If you need customer as a separate Aggregate, then you create customer first, then Assign bank account to existing customer. – DmitriBodiu Apr 24 '20 at 07:14
  • So you have 2 usecases, where second usecase of assigning the account to the customer is a two phase use case. Firt phase is -> find customer, call customer.AssignAccount(account) which would create account + raise domain event account assigned -> Second phase -> catch event and do -> find customer.AssignAccount -> wheere account is added to customer's accounts collection – DmitriBodiu Apr 24 '20 at 07:17

2 Answers2

2

If your aggregate roots both belong to the same bounded context then your aggregate roots should probably be in the same project; else the domain service may be in another project that references the two aggregate root projects but that is going to become unwieldy quite quickly. A domain project per bounded context should suffice.

However, if the two aggregate roots are in separate bounded contexts then the "easiest" would be to use some form of messaging and have a process manager in an orchestration layer handle the interaction between the various bounded context endpoints. For this I usually have BC specific orchestration endpoints and BC specific "functional" endpoints where a functional endpoint handles BC specific functions. A BC specific orchestration endpoint, however, contains the BC specific process managers but typically interacts with other functional endpoints from whichever BC it requires a service to be fulfilled.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • Each aggregate I want to deploy as a separate microservice - that is why they are in separate projects. Make sense? – Mike Lenart Mar 17 '20 at 00:47
  • 1
    That sounds too finely grained. YMMV. Eric Evans has a nice presentation on microservices: https://www.youtube.com/watch?v=yPvef9R3k-M – Eben Roux Mar 17 '20 at 04:17
1

Imagine you're building an ecommerce app. In your case when you create a product, the data should be decomposed by ui micro controllers which belong to their bounded contexts (shipping, invoicing) (like hyenas) and send info they interested in to bounded context data storage for future fulfilling their capabilities. As a shipping isolated module, in order to calculate shipping cost, I need product weight, hence I should tear away that info when user inputs that data on UI.

https://www.youtube.com/watch?v=hev65ozmYPI - Check out this link.

DmitriBodiu
  • 1,120
  • 1
  • 11
  • 22