Должна ли командная информация передаваться в агрегат с использованием параметров метода или по ссылке?

Question

Я работаю над внедрением базового приложения CQRS + ES. Я видел много примеров, но я не понимаю маршрутизацию между обработчиком команд и агрегатом.

В некоторых примерах, работа сделал таким образом:

XCommandHandler:

void Handle(XCommand command) { 
    var aggregate = this.repository.Find<Aggregate>(command.aggId); 

    aggregate.InvokeSomeBusinessLogic(command.property1, command.property2); 
    this.repository.Save(aggregate); 
} 

Но другие делают по-другому:

XCommandHandler:

void Handle(XCommand command) { 
    var aggregate = this.repository.Find<Aggregate>(command.aggId); 

    aggregate.InvokeSomeBusinessLogic(command); 
    this.repository.Save(aggregate); 
} 

Что это лучший подход, особенно когда у вас много свойств (15 или более) в запятой й?

Answer 1

Это не вопрос о CQRS + ES, а просто о дизайне API в целом. Как Clean Code объясняет, метод без параметров лучше, чем метод с одним параметром, который лучше, чем одна с двумя параметрами, и т.д.

Слепо следуя этому правилу всегда должны заставить вас выбрать второй вариант:

aggregate.InvokeSomeBusinessLogic(command); 

Однако слепо следовать за любым правилом редко бывает хорошей идеей. В этом случае, было бы хорошей идеей, чтобы рассмотреть вопрос о Interface Segregation Principle как Противодействие силы:

Клиенты не должны быть вынуждены зависеть от методов, которые они не используют.

Поскольку геттеры и сеттеры тоже являются методами, я думаю, что этот принцип применим и к объектам Command.

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

Другое дело, что если у вас есть объект Command с 15 свойствами, вы можете захотеть переосмыслить свой дизайн. Одним из основополагающих предпосылок CQRS + ES является то, что приложения представляют task-based UIs, что гарантирует, что каждая команда (и соответствующие события) являются «маленькими».

---

Редактирование в комментариях Марки со ссылками, потому что одна из ссылок были сломаны:

Обновление совокупной информации не поручает основе; это CRUD. Возможно, эти две статьи из Udi Dahan будут полезны.

Queries, Patterns, and Search – food for thought

Tasks, Messages, & Transactions – the holy trinity

Answer 2

Я согласен с Марком в принципе. Однако я хотел бы отметить, что CQRS вырос из мира проектирования, управляемого доменом. Они подчеркивают важность языка (ubiquitous language). Вы можете зафиксировать намерение и смысл в фактическом имени объекта команды.

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

У меня есть несколько связанных должностей, которые могут вам помочь. Aggregate Root – How to Build One for CQRS and Event Sourcing и 6 Code Smells with your CQRS Events – and How to Avoid Them. В то время как последний относится к событиям, применяемым многими принципами.

Надеюсь, вы найдете их полезными.