Hi Péter,
Use of the .Tasks layer isn't a necessity for application
development. The purpose of it is to encapsulate coordination
activities (e.g., talking to repositories and web services) within a
separate layer.
Alternatively, the coordination logic could live directly within
controller classes or within the domain. The benefit of getting rid
of it is, of course, reduction in architectural complexity. The
drawback is that the controller is typically seen as being part of the
web layer; so putting the logic in the controller can quickly lead to
concerns bleeding together.
As another alternative, the coordination logic could live directly
within the domain layer, as you suggested. If I had to choose between
putting it in the controller layer or domain layer, I would choose the
domain layer and suffix these "coordination classes" with xxxTasks,
xxxServices, or some other identifiable prefix.
IMO, a separate .Tasks layer is great for larger projects, overkill
for the smaller ones.
Billy McCafferty