DEV Community: Wali Queiroz

Princípios SOLID em GoLang - Dependency Inversion Principle (DIP)

Wali Queiroz — Sat, 03 Aug 2024 17:10:29 +0000

Olá, pessoas!

Estou de volta para concluir nossa série de artigos sobre SOLID, apresentando o princípio que tem o impacto mais significativo nos testes unitários em Go: O Princípio da Inversão de Dependência. Para ver os artigos onde detalho os outros, acesse:

Como desenvolvedor, você já se deparou com softwares altamente acoplados, onde as regras de negócio se misturam com detalhes de apresentação e recursos de bibliotecas externas? Quando é necessário substituir ou alterar uma dessas dependências, muitas partes da aplicação precisam ser modificadas. E aí está uma coisa que todo dev odeia.

Aqui entra o DIP, uma luz no fim do túnel para esse problema. Segundo Robert C. Martin, seu formulador:

“Os módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.”

Mas o que são módulos de alto e baixo nível?

Os módulos de alto nível, nesse contexto, são os componentes mais próximos das regras de negócio da aplicação, enquanto os de baixo nível são as ferramentas que usamos para executar essas regras, eles escondem detalhes técnicos sobre diferentes integrações de infraestrutura. Por exemplo, poderia ser uma struct que contém a lógica para recuperar dados do banco de dados, enviar uma mensagem SQS, buscar um valor do Redis ou enviar uma solicitação HTTP para uma API externa.

O DIP sugere que as regras de negócio não devem interagir diretamente com os recursos utilizados para sua execução. A comunicação deve ocorrer através de interfaces, definidas pelo negócio, e as ferramentas externas ou detalhes de implementação são encapsulados em classes que implementam essas interfaces. Isso pode aumentar um pouco a base de código, mas vale a pena, pois torna o sistema mais flexível e fácil de modificar.

Vamos aos exemplos práticos com Go.

No trecho de código acima definimos um componente de alto nível, TaskService. Esta estrutura tem um método ChangeStatus, responsável por mudar o estado da tarefa, que espera o ID e um novo estado. Observem que nosso componente de alto nível depende diretamente do componente de baixo nível sql.DB. Essa dependência direta aumenta o acoplamento entre componentes, tornando o código mais difícil de manter e evoluir. A substituição do banco de dados ou a introdução de um repositório diferente exige modificações no TaskService, o que viola o princípio da responsabilidade única. Também limita a capacidade de reutilizar o TaskService em diferentes contextos, onde uma implementação diferente de persistência pode ser necessária. Além disso, sem definir uma conexão real com o banco de dados, não podemos inicializar nossa estrutura de caso de uso. Tal anti-padrão impacta diretamente nossos testes unitários em Go. Vejamos:

Em contraste com algumas linguagens, como PHP ou Java, não podemos simplesmente criar mocks de "qualquer coisa" em Go. A criação de mocks aqui depende do uso de interfaces, para as quais podemos definir uma implementação simulada, mas não podemos fazer o mesmo para structs. Portanto, não podemos criar um mock de sql.DB, pois é uma struct. Nesse caso, precisamos criar um mock em um nível mais baixo, instanciando uma conexão falsa, o que podemos conseguir usando o pacote SQLMock.

No entanto, mesmo essa abordagem não é nem confiável nem eficiente para testes. Qualquer mudança dentro do banco de dados requer que adaptemos também os testes unitários. Além dos problemas com testes, temos um dilema ainda maior: o que acontecerá se decidirmos mudar o armazenamento para algo diferente, como MongoDB? Nesse cenário, se continuarmos usando essa implementação de TaskService, isso levará a inúmeras refatorações.

Como aplicar a inversão de dependências

“Os módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.”

Vamos revisitar a diretriz original do Princípio da Inversão de Dependência e focar nas frases em negrito. Elas nos fornecem algumas orientações para o processo de refatoração. Precisamos definir uma abstração (uma interface) da qual nossos componentes, TaskService (alto nível) e sql.DB (baixo nível), dependerão. Esta abstração não deve estar vinculada a nenhum detalhe técnico, somente à entidades que compõem o cerne da regra de negócio. Vamos dar uma olhada no código a seguir:

Na nova estrutura de código, adicionamos a interface TaskRepository como um componente que depende da estrutura Task. Task não reflete diretamente o esquema do banco de dados; em vez disso, usamos a estrutura TaskModel para essa finalidade. Também temos uma função mapTaskModelToTask que facilita o mapeamento para a estrutura Task real.

Nesta configuração, o componente de alto nível depende de uma abstração, pois contém um campo do tipo TaskRepository. Para fazer o componente de baixo nível depender da mesma abstração, aplicamos o pattern Adapter, fazendo com que sql.DB sirva como parte dos detalhes em taskSQLRepository, que atua como a implementação concreta de TaskRepository. Podemos definir quantas implementações para TaskRepository forem necessárias, como taskFileRepository ou taskMongoDBRepository.

Agora nossas estruturas dependem de interfaces e, se precisarmos alterar nossas dependências, podemos definir diferentes implementações e injetá-las. Essa técnica está alinhada com o padrão de Injeção de Dependência (DI), uma prática comum em vários frameworks. A diferença entre injeção de dependência e inversão de dependência é sutil, mas crucial. O DIP é um princípio de design que orienta o desacoplamento de módulos de alto nível dos de baixo nível, enquanto a DI é uma técnica de implementação usada para realizar esse desacoplamento, injetando dependências em vez de criá-las internamente.

Agora, vamos examinar como essa refatoração afeta nossos testes unitários:

Após essa mudança, fica fácil criar mocks. Essa forma de fazer as coisas torna o processo de teste mais simples e elegante. Agora, podemos facilmente usar diferentes versões do TaskRepository para testar diferentes situações e controlar com precisão os resultados dos testes. Mas você pode estar se perguntando: "Eu tenho que fazer isso manualmente?" A resposta é não. No exemplo, criei mocks manualmente apenas para facilitar o entendimento, mas na prática, você pode usar bibliotecas como Mockery e GoMock para gerar automaticamente o código desses mocks com base nas interfaces, o que acelera bastante o desenvolvimento.

Considerações finais

Aumento de Código e Manutenção

Ao aplicar o Princípio da Inversão de Dependência (DIP), é natural que o código aumente em termos de quantidade. A necessidade de criar interfaces e classes adicionais para cumprir o princípio pode parecer um overhead inicialmente. No entanto, essa abordagem traz inúmeros benefícios a longo prazo. O código torna-se mais modular e cada componente se torna independente dos detalhes de implementação dos outros. Isso facilita a manutenção e a evolução do sistema, pois mudanças em uma parte do código não requerem alterações em outras partes, minimizando o risco de introduzir novos bugs.

Facilidade de Teste

Outro benefício crucial de seguir o DIP é a facilidade de testar o código. Quando dependências são abstraídas através de interfaces, é simples substituir implementações reais por mocks ou stubs nos testes unitários. Isso permite que cada parte do sistema seja testada de maneira isolada, garantindo uma cobertura de testes mais eficaz e uma detecção precoce de falhas.

Relevância em Arquiteturas em Camadas

Em arquiteturas modernas, como a Arquitetura Limpa e a Arquitetura Hexagonal, o DIP não é apenas uma recomendação, mas uma necessidade para garantir que o sistema seja robusto, flexível e preparado para mudanças futuras.

E assim concluímos nossa série sobre SOLID em Golang! Espero que tenha sido útil para vocês.

Até a próxima!

Referências:

Princípios SOLID em GoLang - Interface Segregation Principle (ISP)

Wali Queiroz — Sat, 03 Aug 2024 16:47:35 +0000

E aí, galerinha!

Hoje vamos falar sobre o quarto princípio SOLID: o Interface Segregation Principle. Para ver os artigos onde detalho os 3 primeiros, acesse:

O Interface Segregation Principle ou Princípio da Segregação de Interfaces é bem simples de ser compreendido. Ele postula que "nenhum cliente deve ser forçado a depender de métodos que não utiliza". "Cliente", nesse contexto, não são os usuários finais do software, mas os módulos que dependem de uma interface dentro do sistema.

Em outras palavras, o princípio prega que nossas interfaces devem ser concisas, de forma que não precisemos fazer com que as classes ou structs implementem métodos apenas para "respeitar o contrato".

Semelhante ao Princípio da Responsabilidade Única, o objetivo do ISP é reduzir os efeitos colaterais e a frequência das alterações necessárias, dividindo o software em várias partes independentes.

Violando o ISP

Ninguém quer escrever código ruim, mas manter princípios de design nem sempre é fácil ou intuitivo. Com o crescimento do sistema em usuários e funcionalidades, cada mudança se torna um desafio. Às vezes, a solução rápida é adicionar um novo método a uma interface existente, mesmo que não tenha relação direta. Isso pode resolver problemas quando o requisito é o prazo (o que a gente sabe que acontece ⛓️💼💔), mas polui a interface e gera contratos confusos com métodos de diferentes responsabilidades.

Vamos dar uma olhada em um exemplo onde esse tipo de equívoco poderia acontecer.

Começaremos definindo uma interface chamada Phone que representa um telefone celular com funcionalidades básicas, como discar num teclado físico e fazer e receber chamadas.

Nesta etapa, temos uma interface clara e uma implementação para telefones simples. Tudo funciona bem até aqui.

Vamos supor que agora o sistema precise acomodar funcionalidades de smartphones. Uma abordagem inicial para lidar com isso poderia ser incluir todos os métodos de smartphones na interface do telefone básico, como demonstrado abaixo:

Como a interface Phone mudou e mais métodos foram adicionados, todos os seus clientes precisam ser atualizados. O problema é que implementá-los é indesejado e pode levar a muitos efeitos colaterais. Neste ponto, estamos forçando a struct SimplePhone a implementar métodos como TakePhoto() e SendEmail(), mesmo que eles sejam irrelevantes para esse tipo de telefone. O mesmo ocorre com a struct AdvancedPhone, que implementa o método DialPhysicalKeypad() mesmo que smartphones geralmente não o tenham teclado físico. Nesse cenário, as implementações têm que lidar com as funcionalidades não suportadas lançando panics (em outras linguagens a gente vê bastante o uso de exceções nessas situações).

Para evitar a interrupção abrupta de um caso de uso, o código que utiliza essas implementações (como a função performPhoneActions) teria que ser modificado para verificar a capacidade do telefone antes de chamar cada método. Isso funciona? Funciona! Mas não é nada escalável e aumenta bastante a chance de introduzirmos um bug mexendo em código que já existia sem necessidade. Além disso, como já vimos, essa abordagem quebra pelo menos mais dois princípios SOLID, o OCP e o LSP.

Aplicando o Interface Segregation Principle

Na seção anterior poluímos intencionalmente a interface Phone e violamos o ISP. Vejamos como corrigi-lo.

Observando o código com problemas, podemos ver que os métodos MakeCall e ReceiveCall são necessários em ambas as implementações. Por outro lado, DialPhysicalKeypad só é necessário em telefones básicos, e TakePhoto e SendEmail são apenas para Smartphones. Com isso resolvido, vamos dividir as interfaces e aplicar o ISP.

Assim, agora temos uma interface comum:

Mais duas para os respectivos tipos de telefone:

E as respectivas implementações:

Com essa abordagem, conseguimos corrigir muitos problemas do código anterior. Agora, diferentes tipos de telefones têm contratos que fazem sentido para eles. Não precisamos mais nos preocupar com métodos desnecessários ou pânicos. E se quisermos adicionar um novo tipo de telefone ou funcionalidade, podemos fazer isso sem estragar o que já estava funcionando.

Onde aplicar no mundo real?

Imagine que você está desenvolvendo uma aplicação de comércio eletrônico que precisa lidar com diferentes gateways de pagamento para processar transações. Cada gateway tem suas próprias capacidades e limitações. Como você pode garantir que sua aplicação seja flexível e adaptável a essas diferenças?

Inicialmente, você pode criar uma interface única que engloba todas as operações possíveis:

No entanto, a disponibilidade de cada recurso pode variar de uma solução para outra. Alguns gateways de pagamento podem ser mais limitados em termos de funcionalidades e recursos.

Para aplicar o ISP nesse cenário, é sensato separar as operações em interfaces mais específicas, de acordo com a disponibilidade de recursos em cada gateway. Isso permite que você modele de forma precisa o comportamento esperado para cada serviço de pagamentos.

Formas práticas de seguir o ISP

Antes que vocês saiam por aí quebrando toda e qualquer interface em várias de um método só, lembrem-se: não é assim que a banda toca. A depender do seu contexto, pode ser que faça sentido ter uma interface grande. No mundo das interfaces, ao contrário do que podemos ser levados a pensar quando estamos começando a estudar boas práticas, não é a fragmentação que importa, é a coesão. Em vez de se perguntar se suas classes/structs estão lidando com interfaces "inchadas", questionem: "Esses métodos fazem sentido juntos?". Se a resposta for um enigmático "não", refatore o quanto antes!

That's all, folks!

Refrências:

Princípios SOLID em GoLang - Liskov Substitution Principle (LSP)

Wali Queiroz — Mon, 29 Jul 2024 00:51:26 +0000

Hoje vamos falar sobre o Liskov Substitution Principle. Para ver os artigos anteriores da série acesse:

Dentre os princípios SOLID, o LSP é o que tem a definição formal mais complicada. Por outro lado, é o de mais simples execução, porque o conceito é intuitivo e você acaba aplicando sem muito esforço cognitivo na maioria das vezes.

O princípio foi definido por Barbara Liskov da seguinte forma:

"Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T."

Complicado, né?

Mas, no fim das contas, essa definição matemática pode ser traduzida na seguinte sentença:

"Se um ObjetoX é uma instância da ClasseX, e um ObjetoY é uma instância da ClasseY, e a ClasseY herda da ClasseX— se usarmos ObjetoY em vez de ObjetoX em algum lugar do código, a funcionalidade não deve ser interrompida."

Como podemos ver, esse é um princípio que parece estar diretamente ligado aos conceitos de classe e herança, e nenhum dos dois está presente no Go. Então como podemos aplicar?

Já vi alguns artigos explicando o LSP em GoLang utilizando os recursos de composição (embedding) da linguagem, mas, do meu ponto de vista, não é uma boa abordagem, pois a composição não permite substituir a estrutura pai pela estrutura filha. Observem:

A definição do princípio leva muitos (eu incluso por bastante tempo) a pensar que se trata de somente de herança, mas na verdade trata-se de subtipagem. Logo, em Go, o LSP é melhor expresso através do uso de interfaces e polimorfismo. Vamos ao próximo exemplo:

Neste cenário, fizemos o método Refuel() na struct ElectricCar lançar um panic indicando que carros elétricos não podem ser abastecidos com gasolina.

Ao chamar a função PerformVehicleActions() com uma instância de ElectricCar, ocorre uma quebra óbvia do princípio de substituição de Liskov. Embora ElectricCar implemente o método Refuel() definido pela interface Vehicle, a implementação específica do carro elétrico interrompe a execução do programa.

No exemplo, vimos a quebra da funcionalidade da interface em vez de seguir a expectativa. E essa é a sacada do LSP em Go: Uma struct não deve violar o propósito da interface.

Poderíamos alterar o design de modo que o cliente do método Refuel() tenha que estar ciente de um possível erro ao chamá-lo. No entanto, isso significaria que os clientes teriam que ter conhecimento especial do comportamento inesperado do subtipo. Isso começa a quebrar o Open/Closed Principle.

Em resumo, toda violação do LSP se torna uma violação do OCP. Então, como corrigir?

Uma possível modificação para respeitar o princípio seria mudar a interface Vehicle para ter um método mais genérico, como Recharge, em vez de Refuel. Assim, cada subtipo pode implementar esse método de acordo com a sua fonte de energia, seja gasolina ou eletricidade.

Outra possível modificação seria criar uma interface separada para os veículos elétricos, como ElectricVehicle, que tenha um método específico para recarregar a bateria, como RechargeBattery. Assim, o ElectricCar implementaria essa interface e não haveria conflito com o método Refuel.

Aqui está um exemplo de código usando a segunda modificação:

Depois disso tudo vocês podem estar pensando: "Ah, Wali, com código de mentirinha é tudo muito fácil, quero ver no mundo real." Então vejamos um exemplo de aplicação do LSP no mudo real:

Neste exemplo, temos a definição da interface Cache, com os métodos Get, Set e Delete, e as implementações RedisCache e MemoryCache.

O UserService utiliza a interface Cache como dependência, permitindo a troca entre o RedisCache e o MemoryCache sem problemas.

No cenário apresentado, o LSP poderia ser quebrado se a implementação específica de algum método de Cache na struct derivada não cumprisse as mesmas garantias e pré-condições definidas pela interface.

Por exemplo, se a implementação do método Get em MemoryCache lançasse um erro diferente ou não respeitasse a garantia de retornar um erro quando a chave não é encontrada, isso quebraria o LSP. Da mesma forma, se a implementação do método Set em RedisCache não armazenasse corretamente os valores no Redis, ou a implementação do método Delete não excluísse corretamente as chaves, isso também violaria o LSP.

Isso é tudo, pessoal! Até a próxima!

Referências:

Princípios SOLID em GoLang - Open/Closed Principle (OCP)

Wali Queiroz — Mon, 29 Jul 2024 00:27:48 +0000

Dando continuidade à série sobre os princípios SOLID em Go, hoje vamos falar sobre o Open/Closed Principle (OCP). Para ler o primeiro artigo acesse:

Princípios SOLID em GoLang - Single Responsability Principle (SRP)

A definição formal do OCP diz que "um artefato de software deve estar aberto para extensão, mas fechado para modificações".

Este é provavelmente o princípio mais polêmico e difícil de assimilar logo de cara, afinal de contas, software é evolutivo, é incomum que um programa seja desenvolvido uma vez e nunca mais modificado. Então onde esse princípio tenta chegar?

Se uma nova funcionalidade precisa ser adicionada, deve ser possível implementá-la criando uma nova classe, módulo ou função, sem precisar modificar o código de outras partes do sistema. Isso significa que as entidades de software devem ser projetadas de forma modular e coesa, com interfaces claras e contratos bem definidos.

Em resumo, o "fechado para modificações" do OCP não significa que o software nunca pode ser modificado, mas sim que as modificações devem ser realizadas de forma consciente e planejada, sem gerar impactos negativos.

Agora vamos sair da teoria e ver como isso funciona na prática com GoLang. Vejamos primeiro um exemplo mais lúdico. Observem o código abaixo:

A struct Calculator possui um método sumAreas que define como parâmetro a variável shapes, que pode ser qualquer coisa. Linhas a frente podemos encontrar um switch-case para mapear cada tipo possível.

O que aconteceria se definíssemos uma forma Triangle e quiséssemos que a área dela fosse somada também? Teríamos que modificar a função sumAreas para mapeá-la e realizar o cálculo, certo? Por esse motivo, o código acima quebra o Open/Closed Principle; para cada nova forma, uma modificação é necessária em sumAreas. Isso pode afetar negativamente a manutenibilidade do código, aumentando a complexidade, o risco de erros e a dificuldade de alterações futuras.

Então como resolver?

Podemos delegar a responsabilidade do cálculo das áreas às suas respectivas formas geométricas (alô SRP) e fechar um contrato através de uma interface chamada Shape com um método Area(). Vejamos:

Neste exemplo, a função sumAreas está aberta para extensão porque podemos adicionar novas formas que implementam a interface Shape sem modificá-la. Ela também está fechada para modificação porque não precisamos alterar seu código interno para lidar com novas formas.

Mas e no mundo real, onde podemos aplicar o Open/Closed Principle?

Vamos supor que você esteja desenvolvendo um sistema de e-commerce e precisa calcular o frete para entrega dos produtos. A função que faz esse cálculo poderia facilmente ser escrita assim:

O problema com essa implementação é da mesma natureza do que vimos no caso das formas geométricas: sempre que uma nova transportadora for adicionada, será necessário modificar a função CalculateShipping.

Para corrigir essa violação do OCP, podemos criar uma interface ShippingProvider que define um método CalculateShipping e, em seguida, implementar uma struct para cada transportadora. A função CalculateShipping pode receber uma instância da struct correspondente e delegar o cálculo do frete para ela.

Formas práticas de seguir o OCP

Do meu ponto de vista, o Open/Closed Principle é o mais complicado e consequentemente incompreendido dentre os 5 princípios SOLID. Nesse artigo eu trouxe exemplos onde fica claro quando aplicá-lo, mas no dia a dia nem sempre vai ser assim. Precisamos ser capazes de identificar corretamente áreas no código que precisam ser isoladas para que possam ser modificadas sem afetar outras partes do sistema (pontos de variação). Ao mesmo tempo, não queremos desenvolver software com muita complexidade inicial. Tendo isso em mente, aqui estão maneiras práticas de seguir OCP:

Se você ainda não consegue identificar os pontos de variação em seu código, comece de um jeito simples, mas não simplório. Então, à medida que o sistema evolui, faça sua refatoração e construa a abstração correta em torno desses pontos.
Se você conhece seus pontos de variação antecipadamente, tente identificar o nível certo de abstração que seu software precisa sem complicar demais as coisas.

Isso é tudo, pessoal! Até a próxima!

Referências:

Princípios SOLID em GoLang - Single Responsability Principle (SRP)

Wali Queiroz — Mon, 29 Jul 2024 00:15:54 +0000

No mundo do desenvolvimento de software, os princípios SOLID nos dizem como organizar funções e dados de forma que nossos códigos:

Tolerem mudanças
Sejam fáceis de entender
Sejam a base de componentes que podem ser usados em muitos sistemas de software

O termo SOLID é um acrônimo para cinco postulados de design, descritos a seguir:

(S) Single Responsability Principle (Princípio da Responsabilidade Única): "Um módulo deve ter um, e apenas um motivo para mudar"
(O) Open/Closed Principle (Princípio Aberto/Fechado): "Um artefato de software deve estar aberto para extensão, mas fechado para modificações"
(L) Liskov Substitution Principle (Princípio de Substituição de Liskov): "Uma classe derivada deve ser substituível por sua classe base"
(I) Interface Segregation Principle (Principio da Segregação de Interface): "Uma classe não deve ser forçada a implementar interfaces e métodos que não utilizará"
(D) Dependency Inversion Principle (Principio da Inversão de Dependência): "Dependa de abstrações e não de implementações"

SOLID e GoLang

O SOLID é pensado para programação orientada a objetos, e é sabido que GoLang não é uma linguagem que adota esse paradigma. Contudo, podemos usar os recursos que ela disponibiliza para atender à metodologia POO. Por exemplo, Go não tem suporte de herança, mas a ideia pode ser compensada com seu suporte de composição. Da mesma forma, um tipo de polimorfismo pode ser criado usando interfaces.

Nesse artigo, o primeiro de uma série de 5, pretendo detalhar o primeiro princípio com exemplos que se aproximam de situações que nos deparamos no dia a dia.

Single Responsibility Principle (SRP)

Já sabemos o que o termo significa, agora é hora de aprender como implementá-lo em GoLang.
Nessa linguagem, poderíamos definir este princípio como “Uma função ou tipo deve ter um e apenas um trabalho, e uma e apenas uma responsabilidade”, vejamos o seguinte código:

Acima, temos uma struct que chamamos de userService. Ela tem duas propriedades: db que é responsável pela comunicação com um banco de dados relacional, e amqpChannel, que viabiliza a comunicação com o serviço de mensageria RabbitMQ.

UserService implementa um método chamado Create. Dentro desse método armazenamos as informações do usuário recebido no banco de dados e, em seguida, publicamos os dados no RabbitMQ.
Percebe-se que a responsabilidade do método Create no userService não é apenas uma, e sim, duas: armazenar uma informação no banco de dados e publicar uma mensagem numa fila do RabbitMQ.

Isso pode levar a vários problemas, como:

Dificuldade de manutenção: se um dos requisitos mudar, como por exemplo, a forma como os dados do usuário são serializados, você terá que modificar a lógica do método Create, mesmo que isso não tenha nada a ver com a sua responsabilidade principal, que é salvar os dados no banco de dados.
Dificuldade de teste: como o método Create tem duas responsabilidades diferentes, você terá que criar testes para cada uma delas, o que pode ser difícil e trabalhoso.
Acoplamento desnecessário: a lógica de publicação dos dados do usuário em uma fila do RabbitMQ é totalmente independente da lógica de salvar esses dados num banco de dados. Misturar essas duas responsabilidades no mesmo método cria um acoplamento desnecessário.

No código a seguir, modificamos a estrutura para respeitar o SRP. Vejam só:

Observe que separamos as responsabilidades em três partes distintas: o repositório UserRepository para persistir o usuário no banco de dados, o publicador UserPublisher para enviar uma mensagem para o RabbitMQ e o serviço UserService que orquestra essas duas operações.

Dessa forma, cada componente é responsável por uma tarefa específica e independente, facilitando a manutenção e evolução do código, além de permitir que cada uma dessas partes possa ser substituída ou aprimorada sem afetar as outras. Por exemplo, se for necessário mudar o banco de dados utilizado, basta substituir o repositório. Se for necessário alterar a forma de comunicação, basta alterar o publicador.

Vale ressaltar que há uma diferença sutil entre executar duas tarefas distintas e delegar a execução delas. No exemplo original do userService.Create, havia a execução de duas operações em um único lugar, violando o princípio da responsabilidade única. Após a refatoração, delegamos as execuções para structs distintas e o método Create ficou responsável apenas por coordenar este fluxo.

Para aplicar o SRP neste exemplo, também acabamos implementando alguns dos outros princípios SOLID:

O Interface Segregation Principle (ISP): cada interface representa uma única responsabilidade. Tanto o UserRepository quanto o UserPublisher são interfaces que possuem apenas um método, cada um representando uma única responsabilidade.
O Dependency Inversion Principle (DIP): a struct userService depende de abstrações (interfaces) e não de implementações concretas, ou seja, ela não conhece a implementação específica do UserRepository e do UserPublisher, apenas as interfaces que eles implementam.
O Open/Closed Principle (OCP): o código está aberto para extensão, uma vez que novos repositórios ou publicadores podem ser facilmente adicionados sem modificar userService.

Nos próximos artigos dessa série trarei uma explicação mais detalhada de cada um deles, com exemplos específicos.

Até mais, galera!

Referências:
SOLID: The First 5 Principles of Object Oriented Design
Clean Coder Blog - The Single Responsibility Principle