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?
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
ChangeOfAddressrequest 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.