Jakie są zalety użycia CommandBus'a zamiast zwykłego serwisu?

Opcja pierwsza, command'y:

• SubmitArticleCommand -> SubmitArticleCommandHandler
• PreviewArticleCommand -> PreviewArticleCommandHandler

wszystko spięte CommandBus'em.

Opcja druga, serwis/fasada:

• SubmitArticleDto -> ArticleService --- deleguje --> ArticleSubmitter
• PreviewArticleDto -> ArticleService --- deleguje --> ArticlePreviewer.

W tym wypadku mamy fasadę ArticleService, która spina odpowiednie serwisy.

Jaka jest zaleta użycia CommandBus'a (poza możliwością podpięcia logowania)?

Jak na razie to widzę same problemy.

Na przykład rzucanie wyjątków. Powiedzmy, że nasz SubmitArticleCommandHandler rzuca jakieś wyjątek. W tym momencie nie wiemy czy i jaki wyjątek może zostać wyrzucony podczas wykonania tej komendy. Muszę ręcznie znaleźć odpowiedniego CommandHandler'a (w przypadku serwisu mogę się po prostu przeklikać w IDE), a później sprawdzić jakie wyjątki są wyrzucane przez mojego commanda. Ide mnie nie informuje jakie wyjątki mogą zostać wyrzucone w miejscu wywołania commandBus.dispatch(command) (w przypadku serwisu od razu widzę, co jest nieobsłużone).

Jeśli Twój commandbus jest w pełni synchroniczny i wszystko działa w tym samym procesie (aka mediator), to jedyną zaletą jak już zauważyłeś jest możliwość implementowania cross cutting concerns takich jak logowanie w jednym miejscu.

Natomiast kwestią sporną jest w podejściu synchronicznym do cqrs, czy komendy powinny zwracać jakąkolwiek informację o przebiegu wykonania(błędy) czy ostatecznym rezultacie komendy do kodu wywołującego. Są zwolennicy jednego jak i drugiego podejścia ;)

Czyli tak na dobrą sprawę w podejściu synchronicznym te dwie rzeczy są z grubsza tożsame, a dopiero gdy chciałbym to skalować i obsługiwać komendy asynchronicznie, to wtedy command bus zaczyna lśnić?

Pytanie jak w takim razie poinformować użytkownika, że coś się spieprzyło... i czy w ogóle mi to potrzebne.. bo przy rejestracji użytkownika takie podejście raczej się nie sprawdzi ;) ale to już chyba wychodzi poza temat tego posta. Dzięki :)

Czyli tak na dobrą sprawę w podejściu synchronicznym te dwie rzeczy są z grubsza tożsame, a dopiero gdy chciałbym to skalować i obsługiwać komendy asynchronicznie, to wtedy command bus zaczyna lśnić?

Tak, dokładnie - jak sam zresztą zauważyłeś w pierwszym poście ;-)

Pytanie jak w takim razie poinformować użytkownika, że coś się spieprzyło

Wrzucasz każde wykonywane polecenie do bazy, nadając mu jakiś unikalny id*, i potem co chwilę odpytujesz backend o stan tego polecenia.
W wersji fancy można wykorzystać callbacki / webhooki.

* zwyczajowo polecenia w command busie nie powinny zwracać żadnych danych (są w końcu asynchroniczne), stąd częstym schematem jest generowanie UUID poziom wyżej (w funkcji wywołującej polecenie) i przekazywanie go do polecenia jako parametr.