First approach:

Handler calls repository to associate Google user

Repository has business rules, when this happens, we:

Associate the user in google_users

Create a subscription

it is procedural, the request it is processed instruction by instruction, there isn't any asynchonousness involved, and the answer is returned when each and every instruction has been run. It borders all or nothing approach. It is easy to read and to maintain.

Second approach:

Handler calls repository to associate Google User

Repository associates google_users record

Handler fires event (Google User Associated)

Event then has listeners, one of them is Create Subscription

Event executes and creates the subscription

it is reactive, the request it is decomposed and dispatched to the registered events knowledgable in processing it, it offers the benefits of reactive systems (resilience, responsiveness, elasticity, message drivenness). The answer could be returned at any stage of the process. It is easy to extend and difficult to maintain (try adding business rules precedence in an event driven system).

What is the best of the two?

Scaling the solution could unclutter the clutterness. Imagine along with the subscription a user profile has to be added too.
With the first approach it translates to a new instruction calling the add user profile use case after or before creating the subscription. The time to respond to a request increases.
With the second approach it translates to a new event calling the add user profile use case subscribed to the handler. The response time is unchanged since the handler dispatches the event and sends the response to the request initiator that it will be notified after its request processing is finished.

Knowing just what has been described I tend to opt for the first approach. Knowing the entire landscape most probably changes my option in favour of the second approach.

First approach:

Handler calls repository to associate Google user

Repository has business rules, when this happens, we:

Associate the user in google_users

Create a subscription

it is procedural, the request it is processed instruction by instruction, there isn't any asynchonousness involved, and the answer is returned when each and every instruction has been run. It borders all or nothing approach. It is easy to read and to maintain.

Second approach:

Handler calls repository to associate Google User

Repository associates google_users record

Handler fires event (Google User Associated)

Event then has listeners, one of them is Create Subscription

Event executes and creates the subscription

it is reactive, the request it is decomposed and dispatched to the registered events knowledgable in processing it, it offers the benefits of reactive systems (resilience, responsiveness, elasticness, message drivenness). The answer could be returned at any stage of the process. It is easy to extend and difficult to maintain (try adding business rules precedence in an event driven system).

What is the best of the two?

Scaling the solution could unclutter the clutterness. Imagine along with the subscription a user profile has to be added too.
With the first approach it translates to a new instruction calling the add user profile use case after or before creating the subscription. The time to respond to a request increases.
With the second approach it translates to a new event calling the add user profile use case subscribed to the handler. The response time is unchanged since the handler dispatches the event and sends the response to the request initiator that it will be notified after its request processing is finished.

Knowing just what has been described I tend to opt for the first approach. Knowing the entire landscape most probably changes my option in favour of the second approach.

First approach:

Handler calls repository to associate Google user

Repository has business rules, when this happens, we:

Associate the user in google_users

Create a subscription

it is procedural, the request it is processed instruction by instruction, there isn't any asynchonousness involved, and the answer is returned when each and every instruction has been run. It borders all or nothing approach. It is easy to read and to maintain.

Second approach:

Handler calls repository to associate Google User

Repository associates google_users record

Handler fires event (Google User Associated)

Event then has listeners, one of them is Create Subscription

Event executes and creates the subscription

it is reactive, the request it is decomposed and dispatched to the registered actors knowledgable in processing it, it offers the benefits of reactive systems (resilience, responsiveness, elasticity, message drivenness). The answer could be returned at any stage of the process. It is easy to extend and difficult to maintain (try adding business rules precedence in an event driven system).

What is the best of the two?

Scaling the solution could unclutter the clutterness. Imagine along with the subscription a user profile has to be added too.
With the first approach it translates to a new instruction calling the add user profile use case after or before creating the subscription. The time to respond to a request increases.
With the second approach it translates to a new event calling the add user profile use case subscribed to the handler. The response time is unchanged since the handler dispatches the event and sends the response to the request initiator that it will be notified after its request processing is finished.

Knowing just what has been described I tend to opt for the first approach. Knowing the entire landscape most probably changes my option in favour of the second approach.

First approach:

Handler calls repository to associate Google user

Repository has business rules, when this happens, we:

Associate the user in google_users

Create a subscription

it is procedural, the request it is processed instruction by instruction, there isn't any asynchonousness involved, and the answer is returned when each and every instruction has been run. It borders all or nothing approach. It is easy to read and to maintain.

Second approach:

Handler calls repository to associate Google User

Repository associates google_users record

Handler fires event (Google User Associated)

Event then has listeners, one of them is Create Subscription

Event executes and creates the subscription

it is reactive, the request it is decomposed and dispatched to the registered events knowledgable in processing it, it offers the benefits of reactive systems (resilience, responsiveness, elasticity, message drivenness). The answer could be returned at any stage of the process. It is easy to extend and difficult to maintain (try adding business rules precedence in an event driven system).

What is the best of the two?

Scaling the solution could unclutter the clutterness. Imagine along with the subscription a user profile has to be added too.
With the first approach it translates to a new instruction calling the add user profile use case after or before creating the subscription. The time to respond to a request increases.
With the second approach it translates to a new event calling the add user profile use case subscribed to the handler. The response time is unchanged since the handler dispatches the event and sends the response to the request initiator that it will be notified after its request processing is finished.

Knowing just what has been described I tend to opt for the first approach. Knowing the entire landscape most probably changes my option in favour of the second approach.