Disadvantages when combining several commands during one request/process in CQRS approach?

Question

Software design

When studying CQRS ( synchronously, without ES ), several questions arose, for which, alas, I did not find direct information on the Internet. Everywhere they give examples of primitive applications consisting of 2-3 commands, such as: create a user, get his data, delete, etc.
Questions:
1. Suppose my system has 2 commands (command) and their handlers (command handlers): 1 - creates a user, 2 - activates his account. But then business comes in and says: "For users who have an email address from gmail, accounts should be activated immediately, at the time of creation." What should the controller that handles the request to create a user look like in this case? Should it, after calling the user creation handler, immediately call the account activation handler if the mail address is from gmail? The question can be formulated as follows: does the approach of combining command handlers when processing a single request have any disadvantages?
2. How correct is the approach to take into account that the commands and their handlers will be reusable, for example, when creating an api to the system? Here is an example of a blog. We, in the blog, have a page with the article itself, on which, in addition to the article, additional information is displayed. elements, for example, "5 related articles". In the case of a website, our query handler, in addition to information about the article, will also select "5 similar articles" from the store. In the case of the API, the "/post/1/details" endpoint should return only the information about the article, without the "5 related articles". Personally, I see 2 options for designing commands (in this case, this is query) and their handlers: 1 - for a website, these are PostDetailsQueryHandler and SimilarPostsQueryHandler (again, the question about command combinations in my first question), then api will use only PostDetailsQueryHandler.

Answer 1

Well, IT depends as they say, but:
1. everything is interesting here - in CQRS everyone forgets about the need to support VERSIONING COMMAND. Yes Yes. And the code is very rarely removed from the system to support old versions
2. stop doing garbage, realize that these are two different microservices. Accordingly, the endpoints at the bottom are different. If you want to do it with one request - put something like GraphQL on top

Answer 2

>account activation handler if email address is from gmail?
I don’t see any problems so that the handler, in this case, creates a command to activate the account itself.
>Personally, I see 2 options for designing commands
working scheme, but you start multiplying entities where this is not particularly required, make your site use the same API that third-party services will use, and make it the same for everyone.
It seems to me that it would be nice to separate the actions of "requesting an article" and "receiving recommendations for an article".

Answer 3

1. Suppose my system has 2 commands (command) and their handlers (command handlers): 1 - creates a user, 2 - activates his account. But then business comes in and says: "For users who have an email address from gmail, accounts should be activated immediately, at the time of creation." What should the controller that handles the request to create a user look like in this case? Should it, after calling the user creation handler, immediately call the account activation handler if the mail address is from gmail? The question can be formulated as follows: does the approach of combining command handlers when processing a single request have any disadvantages?

After executing the command to create a user, you need to publish an event about this, and then some handler in its code will check email and if it is from gmail, then it will generate a command to activate it and then to its bus, or wherever you have ...