4

I know that DDD is good with a Task-Based UI, but I'm refactoring a legacy app, where I have Anemic Domain Model (many setters without business logic).

One of the first steps was to make it reach model and add Domain Events. While adding events for creating (TaskCreated in constructor) and removing (TaskRemoved) the model is an easy process, I'm struggling with updating the model.

We have a RESTful API with PUT /tasks/{id} endpoint. Under the hood the framework maps the body of the response to DTO object and then calls setters one by one:

task.setText('new text');
task.setStartDate(newStartDate);
// and so on

I want to listen some event when the task is updated and update it in e.g. Google Calendar. As you can imaging, if I record events in each setter (TextChanged, StartDateChanged) and listen all of them, I will end up with many API calls to the Google API, which is not what I want.

Question is: how should I work with Update operation in the right way? Should I replace all those setters calls with one update(newData) call and dispatch only one domain event there? How to make only one API call to google calendar after the task is updated?

borN_free
  • 1,385
  • 11
  • 19

2 Answers2

1

how should I work with Update operation in the right way?

The usual answer is that the domain events are not part of the object you are modifying, but describe the modifications in a separate data structure.

With an anemic model, I would expect the caller to be responsible for the events. That's probably not the framework if the framework is just auto mapping DTO fields to the task. You want the events to be defined at a point in the code that understands the business context of the edits. In other words, you probably want TaskRescheduled rather than TaskUpdated.

In the first draft, you can just publish the event at the point when you know the save is successful.

More robust is to save the list of events with the task. This gives you better stories around reliable messaging - see Udi Dahan Reliable Messaging Without Distributed Transactions to get a better sense for where this is going.

With a domain model that isn't anemic, you would indeed define the event within the Task update (the event in the data model would still be separate from the state of the task).

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • "With a domain model that isn't anemic, you would indeed define the event within the Task update" and what would be the code for non-anemic model? I mean how to actully update several fields at the same time and whether this is a good idea? – borN_free Feb 16 '17 at 20:12
0

I prefer the one-event-per-set way, because the update action sometimes is just an use case, imagine that you will have to, later in the domain, change just one field of an entity because of an external process, you shall have a command representing that use case and not an entire update.

Now the question arises: how do I track down the events that were fired based on a single use case? Simple, use some kind of correlation identifier, that could be the request Id for example.

To achieve that you may use a list that holds the domain events and, when you save your transaction, you dispatch the events and, as they were created within the same logical context, they will have the same correlation Id.

Ariel Moraes
  • 602
  • 7
  • 15
  • I do not know enough about the details here to judge the technical quality of your answer. But would you like to reduce the impression of a textwall a little? Use newline here and there. Maybe create shorter, more easily read sentences. – Yunnosch Sep 26 '18 at 05:19