Вопрос об использовании DTO с успокаивающим сервисом и извлечением поведения из обновления

В сфере DDD мне нравится идея избегать геттеров и сеттеров для полной инкапсуляции компонента, поэтому единственное разрешенное взаимодействие - это взаимодействие, построенное через поведение. Объединив это с поиском событий, я могу получить хорошую историю того, что было выполнено и когда с компонентом.

Одна вещь, о которой я думал, - это когда я хочу создать, например, спокойный шлюз к базовой службе. В качестве примера предположим, что у меня есть объект Task со следующими методами,

• ChangeDueDate (DateTime date)
• ChangeDescription (строковое описание)
• AddTags (params string [] tags)
• Complete ( )

Теперь очевидно, что у меня будут переменные экземпляра внутри этого объекта для управления состоянием и событиями, которые будут запускаться при вызове соответствующих методов.

Возвращаясь к службе REST, как я вижу, есть 3 варианта:

1. Сделайте URL-адреса в стиле RPC, например http://127.0.0.1/api/tasks/ {taskid} / changeduedate
2. Разрешить отправку множества команд на одну конечную точку, например:
   • URL: http://127.0.0.1/api/tasks/ {taskid} / commands
   • Это примет список команд, поэтому я мог бы отправить следующее в том же запросе:
     • ChangeDueDate команда
     • ChangeDescription команда
3. Сделать действительно доступной команду RESTful, и я создаю логику домена для извлечения изменений из DTO и, в свою очередь, для преобразования в необходимые события, например:
   • URL: http://127.0.0.1/api/tasks/ {taskid}
   • Я бы использовал команду PUT для отправки DTO-представления задачи
   • После получения я могу передать DTO к фактическому объекту домена задачи с помощью метода, который может быть вызван, UpdateStateFromDto
   • Затем он проанализирует dto и сравнит соответствующие свойства с его полями, чтобы найти различия, и может иметь соответствующее событие, которое необходимо запустить, когда оно обнаружит разницу с обнаружено определенное свойство.

Глядя на это сейчас, я чувствую, что второй вариант выглядит лучшим, но мне интересно, что думают об этом другие люди, если есть известный истинный успокаивающий способ справиться с этим видом проблемы. Со вторым вариантом я знаю, что это было бы действительно приятно с точки зрения TDD, а также с точки зрения производительности, поскольку я мог бы объединить изменения в поведении в один запрос, продолжая отслеживать изменения.

Первый вариант определенно будет явным, но приведет к более чем одному запросу, если нужно вызвать много вариантов поведения.

Третий вариант звучит неплохо, но я понимаю, что это потребует некоторых усилий, чтобы прийти с чистой реализацией, которая могла бы учитывать различные типы свойств, вложенность и т. Д.

Спасибо за вашу помощь в этом, правда сгибая голову из-за аналитического паралича. Хотел бы просто посоветовать, что, по мнению других, было бы лучшим из возможных вариантов, или я упускаю какой-то трюк.