CODEWITHSUNDEEP
event-handlingentitydomain-driven-designevent-sourcingaggregateroot
Abhijit Sarkar
Abhijit Sarkar

Reputation: 24568

DDD: How to solve this using Domain-Driven design?

I'm new to DDD and cutting my teeth on the following exercise. The use case is real, but my attempt to solve it with DDD is purely for learning.

We have multiple Git repos, each containing a file that we call product spec. The system needs to respond to a HTTP POST by cloning all the repos, and then update the product spec in those that match some information in the POST body. System also needs to log the POST request as the cause for updating the product spec.

I'd like to use Aggregates and event sourcing for solving this problem because they seem like a good fit. Event sourcing comes with automatic persistence of the commands, so if I convert the POST body to a command, I get auditing for free.

Problem is, the POST may match multiple product spec. I'm not sure how to deal with that. Should I create a domain service, let it find all the matching product spec and then issue an update command to each? Or should I have the aggregate root do so? If using aggregate root to update multiple entities, it itself needs to be an entity, so what would it be in my problem domain?

Upvotes: 0

Views: 758

Answers (2)

Narvalex
Narvalex

Reputation: 1898

The first comment to your question is right (the one of @VoiceOfUnreason): this 'is mostly side effect coordination'. But I will try to answer your question: How to solve this using DDD / Event Sourcing:

  1. The first aggregate root could just be named: 'MultipleRepoOperations'. This aggregate root has only one stream of events.
  2. The command that fires the whole process could be: 'CloneAndUpdateProdSpecRepos' which carries a list of all the repos to be cloned and updated.
  3. When the aggregate root processes the command it will simply spit a bunch of events of type 'UserRequestedToCloneAndUpdateProdSpec'
  4. The second bounded context manages all the repos, and it its subscribed to all the events from 'MultipleRepoOperations' and will receive each event emitted by it. This bounded context aggregate root can be called: 'GitRepoManagement', and has a stream per repo. Eg: GitRepoManagement-Repo1, GitRepoManagement-Repo215, GitRepoManagement-20158, etc.
  5. 'GitRepoManagement' receives each event of type 'UserRequestedToCloneAndUpdateProdSpec', replays its corresponding repo stream in order to rehydrate the current state, and then tries to clone and update the product spec for the repo. When fails emits a failed event or a suceed if appropiate.

Upvotes: 1

giorgi dvalishvili
giorgi dvalishvili

Reputation: 158

for learning purposes try to choose problem domain that has more complex rules and logic, where many actions is needed. for example small game (card game,multiplayer quiz game or whatever). or simulate some real world process like school management or some business process.

Upvotes: 0

Related Questions