0

I am building a feature that is powered by a given table, called Urls, structured as below:

externalId| activatedId | url | userId

This table is populated, driven by 2 scenarios (flows):

  1. Whenever a user creates an account in my system, a event is then consumed from a kafka queue to retrieve the user id and url. These are then persisted Urls on the corresponding columns. So at this point we do have externalId and activatedId nulled .

  2. externalId and activatedId are populated at a later stage, after a user do activate its account. This will mean that userId will also be nulled from table, keeping url untouched.

Given these are two independent flows, and am trying to design both flows in a domain driven approach, i am considering to create 2 repositories, accessig the same Urls table:

  1. UserCreateRepository
  2. UserActivationRepository

Each repository would then have knowledge of it's own representation of the Url:

  1. UserCreateRepository would useUserCreationUrl;
  2. UserActivationRepository would use UserActivationUrl;

I would like to open a discussion to understand what is the best approach, as i feel that having only one repository will mix boths flows and we're handling different scenario entities.

Sammy
  • 767
  • 2
  • 7
  • 25
  • Maybe one of the solutions would be to have 2 different tables that would represent those 2 entities, but they are also related, so am a bit divided here – Sammy May 20 '20 at 10:11

1 Answers1

0

If you want to follow Domain Driven Design approach, you should start modeling the domain at first. The infrastructure part (database, repository) comes later, as it should adjust to already modeled domain. Based on your problem, you should find out what is the aggregate root here. Based on DDD principles you should have only one repository for one aggregate root. Now it's your turn to identify the aggregate. I am thinking that your flow described above consists of two steps:

  • User creates an account: userId and Url for activation is being generated
  • Account must be activated

So, my suggestion is something like this (pseudocode): 

class User : AggregateRoot
{
   SetupAccount(userId, url) {...}
   Activate() {...}
}

It looks like having one aggregate here, only one repository is suitable...

Czarek Szok
  • 86
  • 3