webDEVILopers

Why not take my example and prepare all those methods for a non-legacy scenario but calling them all in one handler - just like the setters you suggested. Then one...

But remember when refactoring your domain model later: keep your aggregates small. Maybe having too much data to change in an Entity should make you rethink your aggregate. As I...

Final note: Removing the setters and having good domain model will move you away from CRUD like style. Since you are talking about HTTP we are not talking about CRUD...

I think there was a similar example in the talk I linked previously @olivergierke: https://www.youtube.com/watch?v=1OgvUIsv96o Looks like a good attempt by @yuloh.

TLDR After having a short look at the discussion I'm wondering why I ever considered "setters" resp. using multiple setters when handling a single command. After some projects with Event...

The alternative approaches were using a Domain Service to ensure that the developer could not pass "incorrectly determined" entered contracts. **A+ES** ```php final class ServiceContract extends AggregateRoot { public static...

Yet another solution would be to go full event-driven. As @BrunoRommens suggests: > What are design implications with this ? Maybe one new aggregate "Available periods" providing a "Reserve period"...

Thanky you very much to @BrunoRommens who draw these diagrams to understand the suggested solutions: * https://twitter.com/BrunoRommens/status/1320073246667059205     

  > This 3rd solution is not exactly what I meant initialy. I think the "non overlaping contract assignment periods" rule deserves its own aggregate, because it only applies...

> I like the idea of making the AssignmentPeriodAvailability an AR. Didin't consider it at first b/c I thought there could be thousands or more taken periods, but that's less...