0

I know that DDD suggests to create separate usecases foreach business operation.

Imagine you have a Player aggregate. It has Address Value Object.

DDD doesn't allow to create an UpdatePlayer() method on PlayerApplication layer. What we should do instead is creating specific usecases in which business is interested. So, instead of UpdatePlayer(), I want to have RelocatePlayerTo(Address newAddress).

What if after relocation, I noticed that I made a mistake in newAddress? How can I adjust the address? For example I misspelled the street name, or entered a wrong unit #.

Should I create a new usecase AdjustPlayerAddress? And a new DomainEvent PlayerAddressHasBeenAdjusted?

Fildor
  • 14,510
  • 4
  • 35
  • 67
DmitriBodiu
  • 1,120
  • 1
  • 11
  • 22
  • I'd call it something that explicitly makes clear that the change is due to a wrong input on the last operation. They need to be separate, because it is not just another relocation. For example: you would maybe want to wipe the wrong address from a list of (valid) residences. – Fildor Jan 30 '19 at 09:51
  • Please spend sometime formatting this question, its unreadable – TheGeneral Jan 30 '19 at 09:55
  • @Fildor There is no any list of valid residences, cause Address in my case is ValueObject. – DmitriBodiu Jan 30 '19 at 10:15
  • @TheGeneral English is not my mother language. Could you please suggest what exactly should be formatted? – DmitriBodiu Jan 30 '19 at 10:16
  • 1
    That was only an example. To put it more generally, since you probably want to / must do different things if you actually add a new dataset in contrast to editing an existing one, they should be different cases. – Fildor Jan 30 '19 at 10:22
  • @Fildor Let's think about it if Player would have Block() and Activate() methods. And it was blocked by mistake. Should I just call Activate() or another separate usecase should be created? it case of address it feels fine to adjust an address. But here it feels like creating a separate use case AdjustStatus() is inappropriate. – DmitriBodiu Jan 30 '19 at 10:34
  • Depends on what `Block()` and `Activate()` do. But anyway: Anything that has "historical" data, you will probably not want to lose even mistakes. Because you might have to deliver proof of "who changed what when (and maybe also why)". – Fildor Jan 30 '19 at 12:14

1 Answers1

0

What if value needs to be corrected?

An important consideration here: is the authoritative source of the data your model, or something else?

For instance, the authoritative source of my address is the real world. The correct spelling depends on all sorts of things that are not under the control of the model. In that case, we should really be thinking of what the model holds as a copy of the data, which is possibly stale.

In that situation, the API for the entity will tend toward the anemic (really, are you going to try to write up all of the different possible reasons why an address might change? and are you sure that I, as the subject, am going to be willing to share those with you?)

However, for situations where the data in question is owned by the model, then it is much more likely that you should be creating specific flows that describe the interesting business processes at work.

Sometimes, it will help to be more precise about what is going on. For instance, what happens if you think of the ChangeOfAddress request being its own thing? and then the problem becomes how does that information move around the rest of your system.

The main idea isn't "Thou shalt not use CRUD", but rather that the language should match that of the domain. Your primary source for spellings of ideas should be your domain experts.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91