Forem: Thiago Souza

Domain Events: Transformando Mudanças em Oportunidades

Thiago Souza — Mon, 17 Nov 2025 00:53:30 +0000

Introdução

E se seu código pudesse anunciar quando algo importante acontece, ao invés de você ter que conectar manualmente todos os sistemas interessados? E se adicionar novos comportamentos não exigisse modificar código existente?

Bem-vindo ao mundo dos Domain Events!

O Problema: Acoplamento em Cascata

Imagine que você precisa implementar: "Quando um cliente for aprovado, envie email e notifique vendas".

Abordagem Ingênua (acoplada)

@Service
public class CustomerService {
    @Autowired private EmailService emailService;
    @Autowired private SalesNotificationService salesService;

    public void approveCustomer(UUID customerId) {
        Customer customer = repository.findById(customerId);
        customer.setStatus(APPROVED);
        repository.save(customer);

        emailService.sendApprovalEmail(customer);
        salesService.notifySalesTeam(customer);
    }
}

Problemas:

Acoplamento direto: Service conhece EmailService e SalesNotificationService
Violação SRP: Aprovar cliente + enviar email + notificar vendas = 3 responsabilidades
Difícil testar: Precisa mockar todos os serviços
Rigidez: Adicionar novo comportamento = modificar código existente
Falha em cascata: Se email falhar, aprovação falha também

Agora imagine adicionar:

Enviar SMS
Atualizar analytics
Notificar sistema externo
Gerar evento no data warehouse
Criar task no CRM

Seu approveCustomer() vira um monstro de 50 linhas com 10 dependências!

Domain Events: A Solução Elegante

Abordagem com Domain Events

public class Customer extends DomainEntity {
    public void approve() {
        if (this.status != CustomerStatus.PENDING) {
            throw new IllegalArgumentException("Customer status is not pending");
        }

        this.status = CustomerStatus.APPROVED;
        this.updatedAt = Instant.now();

        // 🎯 Apenas anuncia o que aconteceu!
        this.recordDomainEvent(new CustomerApproved(this.id()));
    }
}

Vantagens:

Zero acoplamento: Domínio não conhece quem vai reagir
SRP preservado: Apenas muda estado e anuncia
Fácil testar: Não precisa mockar nada
Open/Closed: Adicione listeners sem modificar o domínio
Isolamento de falhas: Listener falha, a entidade não

Anatomia de um Domain Event

Interface Base

package com.github.thrsouza.sauron.domain;

public interface DomainEvent {
    UUID eventId();            // Identificador único do evento
    String eventType();        // Tipo/nome do evento
    Instant eventOccurredAt(); // Quando aconteceu
}

Design decisions:

eventId: Rastreabilidade e idempotência
eventType: Roteamento (nome do tópico Kafka)
eventOccurredAt: Auditoria e ordenação temporal

Implementação com Records

package com.github.thrsouza.sauron.domain.customer.events;

public record CustomerCreated(
    UUID eventId,
    UUID customerId,
    Instant eventOccurredAt
) implements DomainEvent {

    // Construtor conveniente
    public CustomerCreated(UUID customerId) {
        this(UUID.randomUUID(), customerId, Instant.now());
    }

    @Override
    public String eventType() {
        return "sauron.customer-created";
    }
}

Por que Records?

Imutáveis por design: Eventos nunca mudam
Value semantics: equals() e hashCode() automáticos
Serializáveis: JSON de graça com Jackson
Legíveis: Sintaxe concisa e clara

Família de Eventos

// Evento de criação
public record CustomerCreated(UUID eventId, UUID customerId, Instant eventOccurredAt) 
    implements DomainEvent {

    public CustomerCreated(UUID customerId) {
        this(UUID.randomUUID(), customerId, Instant.now());
    }

    @Override
    public String eventType() {
        return "sauron.customer-created";
    }
}

// Evento de aprovação
public record CustomerApproved(UUID eventId, UUID customerId, Instant eventOccurredAt) 
    implements DomainEvent {

    public CustomerApproved(UUID customerId) {
        this(UUID.randomUUID(), customerId, Instant.now());
    }

    @Override
    public String eventType() {
        return "sauron.customer-approved";
    }
}

// Evento de rejeição
public record CustomerRejected(UUID eventId, UUID customerId, Instant eventOccurredAt) 
    implements DomainEvent {

    public CustomerRejected(UUID customerId) {
        this(UUID.randomUUID(), customerId, Instant.now());
    }

    @Override
    public String eventType() {
        return "sauron.customer-rejected";
    }
}

Padrão consistente:

Mesmo construtor conveniente
Mesmo formato de eventType
Payloads mínimos (apenas IDs)

Gerando Eventos na Entidade

DomainEntity Base Class

package com.github.thrsouza.sauron.domain;

public abstract class DomainEntity {
    private final transient List<DomainEvent> domainEvents = new ArrayList<>();

    protected void recordDomainEvent(DomainEvent domainEvent) {
        this.domainEvents.add(domainEvent);
    }

    public List<DomainEvent> pullDomainEvents() {
        List<DomainEvent> copyOfDomainEvents = List.copyOf(this.domainEvents);
        this.domainEvents.clear();
        return copyOfDomainEvents;
    }
}

Design patterns aplicados:

Transient: Eventos não são persistidos com a entidade
Protected: Só a entidade pode registrar eventos
Pull pattern: Quem persiste a entidade recupera os eventos
Defensive copying: List.copyOf() retorna lista imutável
Clear after pull: Evita publicação duplicada

Registrando Eventos

public class Customer extends DomainEntity {

    public static Customer create(String document, String name, String email) {
        UUID id = UUID.randomUUID();
        Instant now = Instant.now();

        Customer customer = new Customer(id, document, name, email, 
                                         CustomerStatus.PENDING, now, now);

        // 🎯 Registra evento de criação
        customer.recordDomainEvent(new CustomerCreated(customer.id()));

        return customer;
    }

    public void approve() {
        if (this.status != CustomerStatus.PENDING) {
            throw new IllegalArgumentException("Customer status is not pending");
        }

        this.status = CustomerStatus.APPROVED;
        this.updatedAt = Instant.now();

        // 🎯 Registra evento de aprovação
        this.recordDomainEvent(new CustomerApproved(this.id()));
    }

    public void reject() {
        if (this.status != CustomerStatus.PENDING) {
            throw new IllegalArgumentException("Customer status is not pending");
        }

        this.status = CustomerStatus.REJECTED;
        this.updatedAt = Instant.now();

        // 🎯 Registra evento de rejeição
        this.recordDomainEvent(new CustomerRejected(this.id()));
    }
}

Observe:

Eventos registrados depois da mudança de estado
Eventos descrevem o que aconteceu (passado)
Nenhuma lógica de negócio nos eventos

Publicando Eventos

No Use Case

public class CreateCustomerUseCase {
    private final CustomerRepository customerRepository;
    private final DomainEventPublisher domainEventPublisher;

    public Output handle(Input input) {
        // Cria uma instância de Customer
        Customer customer = Customer.create(input.document(), input.name(), input.email());

        // Persiste
        customerRepository.save(customer);

        // 🎯 Recupera e publica eventos
        domainEventPublisher.publishAll(customer.pullDomainEvents());

        return new Output(customer.id());
    }
}

Padrão "Pull and Publish":

A entidade gera eventos durante operações
Use case recupera eventos da entidade
Use case delega publicação ao publisher
Publisher envia para infraestrutura (Kafka, RabbitMQ, etc.)

DomainEventPublisher (Interface)

package com.github.thrsouza.sauron.domain;

public interface DomainEventPublisher {
    void publishAll(Collection<DomainEvent> events);
}

Interface no domínio, implementação na infraestrutura!

Implementação Kafka

@Component
public class DomainEventPublisherAdapter implements DomainEventPublisher {
    private final KafkaTemplate<String, Object> kafkaTemplate;

    @Override
    public void publishAll(Collection<DomainEvent> events) {
        events.forEach(this::publish);
    }

    private void publish(DomainEvent event) {
        String topic = event.eventType(); // Nome do tópico vem do evento!

        kafkaTemplate.send(topic, event)
            .whenComplete((result, exception) -> {
                if (exception != null) {
                    log.error("❌ Failed to publish {} to topic {}", 
                             event.getClass().getSimpleName(), topic, exception);
                } else {
                    log.info("📤 Published {} to topic {} (partition: {}, offset: {})",
                            event.getClass().getSimpleName(),
                            topic,
                            result.getRecordMetadata().partition(),
                            result.getRecordMetadata().offset());
                }
            });
    }
}

Observabilidade:

Logs estruturados para debug
Informações de partição e offset
Tratamento de erros centralizado

Consumindo Eventos

Event Listeners

@Component
public class CustomerEventListener {
    private final EvaluateCustomerUseCase evaluateCustomerUseCase;

    @KafkaListener(topics = "sauron.customer-created", 
                   groupId = "${spring.kafka.consumer.group-id}")
    public void handleCustomerCreated(@Payload CustomerCreated event) {
        log.info("📥 Received CustomerCreated event - CustomerId: {}", 
                 event.customerId());

        try {
            evaluateCustomerUseCase.handle(new Input(event.customerId()));
            log.info("✅ Successfully processed CustomerCreated - CustomerId: {}", 
                     event.customerId());
        } catch (Exception e) {
            log.error("❌ Error processing CustomerCreated - CustomerId: {}", 
                      event.customerId(), e);
            throw e; // Relança para retry
        }
    }

    @KafkaListener(topics = "sauron.customer-approved", ...)
    public void handleCustomerApproved(@Payload CustomerApproved event) {
        log.info("📥 Received CustomerApproved - CustomerId: {}", 
                 event.customerId());
        // Aqui: enviar email, notificar vendas, etc.
    }

    @KafkaListener(topics = "sauron.customer-rejected", ...)
    public void handleCustomerRejected(@Payload CustomerRejected event) {
        log.info("📥 Received CustomerRejected - CustomerId: {}", 
                 event.customerId());
        // Aqui: email de rejeição, analytics, etc.
    }
}

Benefícios Reais

1. Auditoria de Graça

Todos os eventos são logados e persistidos no Kafka:

# Lista eventos de um cliente
kafka-console-consumer --bootstrap-server localhost:9092 \
  --topic sauron.customer-created --from-beginning | grep "customerId: 123"

kafka-console-consumer --bootstrap-server localhost:9092 \
  --topic sauron.customer-approved --from-beginning | grep "customerId: 123"

Histórico completo do que aconteceu, quando e por quê!

2. Rastreabilidade Distribuída

1. [14:23:45.123] CustomerCreated published - eventId: abc-123
2. [14:23:45.150] CustomerCreated received - eventId: abc-123
3. [14:23:50.200] CustomerApproved published - eventId: def-456
4. [14:23:50.220] CustomerApproved received - eventId: def-456

Correlação de eventos em sistemas distribuídos!

3. Extensibilidade Sem Modificação

Antes (sem eventos):

// Para adicionar analytics, modifica o código existente
public void approveCustomer(UUID customerId) {
    // ... código existente
    emailService.send(...);
    salesService.notify(...);
    analyticsService.track(...); // ← Nova linha
}

Depois (com eventos):

// Código existente permanece intocado!
@KafkaListener(topics = "sauron.customer-approved")
public void handleCustomerApproved(CustomerApproved event) {
    analyticsService.track(event); // ← Novo listener separado
}

Open/Closed Principle em ação!

4. Testabilidade Aprimorada

@Test
void shouldRecordCustomerApprovedEvent() {
    // Given
    Customer customer = Customer.create("12345", "John", "john@mail.com");

    // When
    customer.approve(); // Score alto aprova

    // Then
    List<DomainEvent> events = customer.pullDomainEvents();
    assertEquals(2, events.size()); // CustomerCreated + CustomerApproved
    assertTrue(events.get(1) instanceof CustomerApproved);
}

Testar eventos é trivial. Sem mocks, sem Spring!

Padrões e Boas Práticas

1. Event Naming (Passado)

// ✅ CORRETO: Verbos no passado
CustomerCreated
OrderShipped
PaymentProcessed
InvoiceGenerated

// ❌ ERRADO: Verbos no imperativo/presente
CreateCustomer
ShipOrder
ProcessPayment
GenerateInvoice

Eventos descrevem fatos que já aconteceram.

2. Payload Mínimo

// ✅ RECOMENDADO: Apenas referências (IDs)
public record CustomerApproved(UUID customerId) {}

// ⚠️ NÃO RECOMENDADO: Dados completos (acoplamento de schema)
public record CustomerApproved(
    UUID customerId,
    String name,
    String email,
    String document,
    Address address,
    CreditScore creditScore
) {}

Por quê?

Reduz acoplamento entre producers e consumers
Consumers buscam dados na versão que precisam
Menores mensagens = melhor performance

3. Eventos São Imutáveis

// ✅ RECOMENDADO: Record (imutável)
public record CustomerCreated(UUID customerId) {}

// ⚠️ NÃO RECOMENDADO: Classe mutável
public class CustomerCreated {
    private UUID customerId; // Pode ser alterado!

    public void setCustomerId(UUID id) {
        this.customerId = id;
    }
}

Eventos são fatos históricos. Não mudam!

4. Eventos Bem Definidos

// ✅ RECOMENDADO: Eventos específicos
CustomerApproved
CustomerRejected

// ⚠️ NÃO RECOMENDADO: Evento genérico
CustomerStatusChanged(UUID customerId, CustomerStatus newStatus)

Eventos específicos são mais semânticos e auto documentados.

Quando Usar Domain Events

✅ Use quando:

Múltiplos sistemas precisam reagir a mudanças
Você quer histórico/auditoria completa
Precisa de desacoplamento entre módulos
Quer extensibilidade sem modificar código existente
Eventual consistency é aceitável

❌ Evite quando:

Consistency forte é obrigatória (ACID)
Resposta síncrona é necessária
Sistema é muito simples (overkill)
Time não tem experiência com async

Conclusão

Ao invés de pensar "o que preciso fazer agora?", pense "o que acabou de acontecer?". Seus entidades se tornam mais focadas, seu código mais testável, e seu sistema mais flexível.

Recursos

Hexagonal Architecture na Prática: Construindo Software Sustentável com Java e Spring Boot

Thiago Souza — Sat, 15 Nov 2025 02:27:14 +0000

Introdução

Proposta por Alistair Cockburn, a Hexagonal Architecture (Ports & Adapters) promete algo que todo desenvolvedor deseja: código que sobrevive ao teste do tempo.

Neste artigo, vou mostrar como implementei essa abordagem no Sauron, um serviço de registro e avaliação de clientes, e como você pode aplicar os mesmos princípios nos seus projetos.

O Problema que Hexagonal Architecture Resolve

Quantas vezes você já viu (ou escreveu) código assim?

@Service
public class CustomerService {
    @Autowired
    private CustomerRepository repository; // JPA vazando por todo lado

    public Customer createCustomer(CustomerDTO dto) {
        Customer customer = new Customer();
        customer.setName(dto.getName());
        // ... mais 50 linhas misturando validação, negócio e persistência
    }
}

Os problemas:

Alto acoplamento com frameworks (Spring, JPA, etc.)
Impossível testar sem subir o contexto Spring
Mudança de banco de dados? Prepare-se para refatorar metade do sistema
Regras de negócio perdidas em meio a anotações e configurações

Hexagonal Architecture resolve isso separando claramente as responsabilidades.

A Estrutura de Camadas

No projeto Sauron, a estrutura é dividida em três camadas principais:

src/main/java/com/github/thrsouza/sauron/
├── domain/           # Camada de Domínio (núcleo)
├── application/      # Camada de Aplicação (casos de uso)
└── infrastructure/   # Camada de Infraestrutura (adaptadores)

Apenas para esclarecer:

Essa é a forma como eu gosto de organizar o meu código.
Arquitetura de software não diz respeito a como diretórios ou pacotes são organizados ou nomeados.

1. Domain Layer: O Coração do Sistema

O domínio é o núcleo do seu sistema. Aqui vivem as regras de negócio puras, sem dependências externas.

package com.github.thrsouza.sauron.domain.customer;

public class Customer extends AggregateRoot {
    private final UUID id;
    private final String document;
    private final String name;
    private final String email;
    private CustomerStatus status;

    public static Customer create(String document, String name, String email) {
        UUID id = UUID.randomUUID();
        Customer customer = new Customer(id, document, name, email, CustomerStatus.PENDING);
        customer.recordDomainEvent(new CustomerCreated(customer.id()));
        return customer;
    }

    public void approve() {
        if (this.status != CustomerStatus.PENDING) {
            throw new IllegalArgumentException("Customer status is not pending");
        }
        this.status = CustomerStatus.APPROVED;
        this.recordDomainEvent(new CustomerApproved(this.id()));
    }
}

Características importantes:

✅ Zero anotações de frameworks (@Entity, @Service, etc.)
✅ Lógica de negócio clara e testável
✅ Invariantes protegidas (não pode aprovar cliente não-pendente)
✅ Factory methods autodescritivos (Customer.create())

2. Application Layer: Orquestrando o Fluxo

A camada de aplicação contém os casos de uso, que orquestram o domínio sem conter lógica de negócio.

package com.github.thrsouza.sauron.application.customer;

public class CreateCustomerUseCase {
    private final CustomerRepository customerRepository;
    private final DomainEventPublisher domainEventPublisher;

    public CreateCustomerUseCase(CustomerRepository customerRepository, 
                                 DomainEventPublisher domainEventPublisher) {
        this.customerRepository = customerRepository;
        this.domainEventPublisher = domainEventPublisher;
    }

    public Output handle(Input input) {
        // Verifica se já existe (idempotência)
        Optional<Customer> existingCustomer = 
            customerRepository.findByDocument(input.document());

        if (existingCustomer.isPresent()) {
            return new Output(existingCustomer.get().id());
        }

        // Cria novo cliente
        Customer customer = Customer.create(
            input.document(),
            input.name(),
            input.email()
        );

        // Persiste e publica eventos
        customerRepository.save(customer);
        domainEventPublisher.publishAll(customer.pullDomainEvents());

        return new Output(customer.id());
    }

    public record Input(String document, String name, String email) {}
    public record Output(UUID id) {}
}

Repare que:

✅ É um POJO puro (Plain Old Java Object)
✅ Dependências explícitas via construtor
✅ Input/Output com Records (imutáveis)
✅ Orquestra domínio, repositório e eventos

3. Infrastructure Layer: Adaptadores para o Mundo Externo

A infraestrutura implementa as interfaces definidas no domínio.

Exemplo: Repository Adapter

@Component
public class CustomerRepositoryAdapter implements CustomerRepository {
    private final CustomerJpaRepository jpaRepository;
    private final CustomerJpaMapper mapper;

    @Override
    public Optional<Customer> findById(UUID id) {
        return jpaRepository.findById(id)
            .map(mapper::toDomain);
    }

    @Override
    public void save(Customer customer) {
        CustomerJpaEntity entity = mapper.toEntity(customer);
        jpaRepository.save(entity);
    }
}

O segredo: Inversão de Dependência

A interface CustomerRepository está no domínio, mas a implementação está na infraestrutura:

// Domain layer (define o contrato)
package com.github.thrsouza.sauron.domain.customer;

public interface CustomerRepository {
    Optional<Customer> findById(UUID id);
    void save(Customer customer);
}

// Infrastructure layer (implementa o contrato)
package com.github.thrsouza.sauron.infrastructure.persistence.jpa.adapter;

@Component
public class CustomerRepositoryAdapter implements CustomerRepository {
    // implementação
}

Isso é Dependency Inversion Principle em ação: módulos de alto nível (domínio) não dependem de módulos de baixo nível (infraestrutura). Ambos dependem de abstrações.

Configuração Manual: Controle Total

No Sauron, os casos de uso são configurados manualmente via @Configuration:

@Configuration
public class UseCaseConfig {
    private final DomainEventPublisher domainEventPublisher;
    private final CustomerRepository customerRepository;

    @Bean
    public CreateCustomerUseCase createCustomerUseCase() {
        return new CreateCustomerUseCase(customerRepository, domainEventPublisher);
    }
}

Por que não usar @Service nos casos de uso?

Mantém a camada de aplicação independente do Spring
Facilita testes unitários (sem contexto Spring)
Deixa as dependências explícitas
Controle total sobre a criação dos objetos

Benefícios Reais

1. Testabilidade

Testar o domínio é trivial:

@Test
void shouldApproveCustomer() {
    Customer customer = Customer.create("12345678900", "John", "john@example.com");
    customer.approve();
    assertEquals(CustomerStatus.APPROVED, customer.status());
}

Sem Spring, sem banco, sem Kafka. Testes rápidos e confiáveis.

2. Substituição de Frameworks

Quer trocar JPA por MongoDB? Apenas crie um novo adapter:

@Component
public class CustomerMongoRepositoryAdapter implements CustomerRepository {
    // Nova implementação
}

O domínio e a aplicação permanecem intocados.

3. Independência de Entrega

O mesmo domínio pode ser exposto via:

REST API (Spring MVC)
GraphQL
gRPC
CLI
Mensageria (Kafka, RabbitMQ)

Basta criar adaptadores diferentes!

Armadilhas Comuns

❌ Domínio Anêmico

// ERRADO: Apenas getters e setters
public class Customer {
    private CustomerStatus status;

    public void setStatus(CustomerStatus status) {
        this.status = status; // Sem validação!
    }
}

✅ Domínio Rico

// CORRETO: Comportamento e validação
public class Customer {
    public void approve() {
        if (this.status != CustomerStatus.PENDING) {
            throw new IllegalArgumentException("Customer status is not pending");
        }
        this.status = CustomerStatus.APPROVED;
    }
}

❌ Vazamento de Infraestrutura

// ERRADO: JPA vazando para o domínio
public interface CustomerRepository {
    Page<Customer> findAll(Pageable pageable); // Pageable é do Spring Data!
}

✅ Abstrações Puras

// CORRETO: Abstrações do domínio
public interface CustomerRepository {
    List<Customer> findAll(int page, int size);
}

Quando NÃO usar Hexagonal Architecture

Hexagonal Architecture não é bala de prata. Evite em:

Protótipos ou MVPs descartáveis
CRUD simples sem lógica de negócio
Scripts ou ferramentas internas
Projetos com deadline apertado e time inexperiente

Para esses casos, um MVC tradicional pode ser mais adequado.

Conclusão

Hexagonal Architecture não é sobre estrutura de pastas ou quantidade de camadas. É sobre separação de responsabilidades, testabilidade e independência de frameworks.

Lembre-se: Arquitetura é sobre trade-offs. Hexagonal Architecture adiciona complexidade inicial em troca de sustentabilidade a longo prazo. Escolha sabiamente!

Recursos

Operadores de Conversão Explícitos e Implícitos Customizados em .NET C#

Thiago Souza — Mon, 27 Jan 2025 11:45:00 +0000

Os operadores de conversão implicit e explicit foram introduzidos na linguagem C# há quase duas décadas. Embora não seja um problema, é provável que muitos programadores nunca tenham tido contato com esse recurso. Por isso, preparei um exemplo didático para apresentar esse recurso a quem ainda não o conhece.

Operadores Explícitos

O objetivo principal dos operadores explícitos é proporcionar maior segurança ao realizar conversões críticas ou potencialmente arriscadas, comumente chamadas de cast (ou conversão explícita).

Antes de explicar como customizá-los, preciso mostrar um exemplo para quem ainda não está familiarizado com este tema:

int temperature = 255;

Console.WriteLine((byte)temperature);

// OUTPUT: 255

Neste caso, estamos realizando uma conversão explícita de uma variável do tipo int para byte.

Se alterássemos este exemplo e o valor informado fosse 256, qual seria o resultado? Experimente.

Agora que estamos familiarizados com o cast, podemos seguir com o nosso exemplo de implementação. Veja o código a seguir:

public class Temperature
{
    public decimal Celsius { get; set; }

    public static explicit operator decimal(Temperature temperature)
    {
        return temperature.Celsius;
    }
}

Além da propriedade Celsius, nossa classe Temperature possui a assinatura e a implementação de um operador de conversão explícita, que recebe uma instância da classe Temperature e retorna o valor da propriedade Celsius (do tipo decimal).

Observe o código a seguir:

Temperature marsTemperature = new Temperature { Celsius = -63.0m };

decimal celsius = (decimal)marsTemperature; // Cast

Console.WriteLine($"Temperature: {celsius}ºC");

// OUTPUT: Temperature: -63.0ºC

Acabamos de instruir o compilador sobre como tratar uma conversão explícita de uma instância de Temperature para o tipo decimal. É um recurso útil.

Agora, vamos aos operadores implícitos.

Operadores Implícitos

O objetivo dos operadores de conversão implícita é, basicamente, melhorar a legibilidade do código. Sendo assim, seu código pode ficar menos verboso e mais transparente, permitindo a realização de conversões de tipos de forma mais segura.

Veja o exemplo a seguir:

public class Temperature
{
    public decimal Celsius { get; set; }

    public static implicit operator Temperature(decimal value)
    {
        return new Temperature { Celsius = value };
    }

    public override string ToString()
    {
        return $"Temperature: {Celsius}ºC";
    }
}

Novamente, além da propriedade Celsius, nossa classe Temperature possui a assinatura e a implementação de um operador de conversão implícita, que recebe um valor do tipo decimal e retorna uma instância da classe Temperature.

Como podemos observar, também estamos sobrescrevendo o método ToString, apenas para deixar o nosso output mais elegante.

No exemplo de código a seguir, criamos uma variável do tipo Temperature, que será instanciada com o valor em decimal que representa a temperatura média do planeta Terra:

Temperature earthTemperature = 14.5m;

Console.WriteLine(earthTemperature);

// OUTPUT: Temperature: 14.5ºC

Conforme pudemos observar neste exemplo, os operadores de conversão implícita são uma excelente ferramenta para simplificar o código e melhorar a legibilidade, mas devem ser usados com cautela para evitar conversões indesejadas e perda de dados.

Neste artigo, vimos os operadores de conversão explicit e implicit em C# e como eles podem ser utilizados para tornar o código mais seguro e legível.

Se você tem alguma dúvida ou sugestão, sinta-se à vontade para deixar um comentário. Ficarei feliz em tentar ajudar!

Me siga para mais conteúdos como este.

Obrigado pela leitura.

DIP - O Princípio da Inversão de Dependência

Thiago Souza — Thu, 16 Jan 2025 10:50:00 +0000

O DIP (Dependency Inversion Principle) é último dos 5 Princípios do acrônimo SOLID. Isso não faz deste princípio o menos ou mais importante que os demais, mas sim tão importante quanto.

Definição do DIP

Novamente, não trouxe nenhuma frase impactante escrita (ou dita) por alguma estrela do desenvolvimento e/ou arquitetura de software, mas podemos definir e afirmar que:

Para reduzir o acoplamento, uma classe/tipo não deve depender diretamente de implementações concretas.

As abstrações (interfaces ou classes abstratas) funcionam como contratos. Isso quer dizer que não importa como a implementação foi feita ou qual biblioteca está sendo usada, desde que a classe/tipo injetado seja capaz de atender o contrato estabelecido.

Quando falamos de classes/tipos concretos, podemos ignorar aqueles que são considerados não voláteis, ou seja, que são estáveis e improváveis de sofrer alterações a qualquer momento por necessidades técnicas ou de negócio.

Um exemplo de classe concreta considerada não volátil é StringBuilder. Apesar de implementar a interface ISerializable, ela é uma classe genérica, estável e improvável de sofrer mudanças drásticas em sua implementação. Além disso, não possui dependências externas que possam causar qualquer tipo de instabilidade.

Agora, como de costume, vamos seguir com os nossos exemplos de violação e de aplicação. Caso não tenha entendido, peço que não se preocupe e eu garanto que você vai sair deste artigo totalmente esclarecido.

Violação do DIP

Vamos observar o seguinte código:

public class EmailService 
{
    public void Send(string destination, string message) 
    {
        // Lógica para realizar o envio de E-mail.
    }
}

public class Notifier 
{
    private readonly EmailService _emailService;

    public Notifier(EmailService emailService) 
    {
        _emailService = emailService;
    }

    public void Notify(string destination, string message) 
    {
        _emailService.Send(destination, message);
    }
}

Podemos notar que a classe Notifier tem uma dependência direta da classe EmailService. Sempre que a EmailService for alterada ou um novo serviço de notificação for implementado, a classe Notifier será obrigada a ser modificada e recompilada pois está fortemente acoplada à implementação da classe EmailService.

Como já falamos em outros artigos, um dos nossos principais objetivos é evitar alto acoplamento no código. Um sistema fortemente acoplado torna-se difícil de manter, aumentando a chance de introduzir erros ao alterar algo que já está validado e publicado no ambiente de produção, violando também o OCP (Princípio Aberto/Fechado).

Aplicação do DIP

Agora, vamos refatorar esse código para seguir o Princípio da Inversão de Dependência (DIP) e observar os benefícios que essa abordagem traz para o design do software:

public interface INotificationService 
{
    void Send(string destination, string message);
}

public class EmailService : INotificationService 
{
    public void Send(string destination, string message) 
    {
        // Lógica para realizar o envio de E-mail.
    }
}

public class Notifier 
{
    private readonly INotificationService _notificationService;

    public Notifier(INotificationService notificationService) 
    {
        _notificationService = notificationService;
    }

    public void Notify(string destination, string message) 
    {
        _notificationService.Send(destination, message);
    }
}

Após a refatoração, a classe Notifier depende agora de uma interface chamada INotificationService. Pouco importa se a implementação injetada enviará notificações via e-mail, SMS ou até mesmo sinal de fumaça. O que importa é que a implementação atenda ao contrato definido pela interface, implementando o método Send, que recebe os parâmetros referentes ao destino e à mensagem que deve ser enviada.

A ideia é direta.

Adotar os princípios SOLID é uma boa prática que promove a criação de códigos mais flexíveis, escaláveis e de fácil manutenção. Claro, você não é obrigado a segui-los, mas, na minha opinião, a longo prazo, os benefícios de aplicá-los superam em muito os desafios iniciais.

A partir daqui, avalie oportunidades de aplicar o princípio no seu código.

Obrigado pela leitura.
Para aprofundar: Arquitetura Limpa — O Guia do Artesão para Estrutura e Design de Software (Robert C. Martin, 2019).

ISP - O Princípio da Segregação de Interface

Thiago Souza — Mon, 13 Jan 2025 13:50:00 +0000

O ISP (Interface Segregation Principle) foi formulado e utilizado pela primera vez por Robert C. Martin (o famoso Uncle Bob), enquanto ele realizava uma consultoria para a Xerox.

Este princípio, na minha opnião, é o mais simples dos 5 Princípios SOLID e, ao mesmo tempo, o mais negligenciado dentre os desenvolvedores e arquitetos de software. No entanto, isso depende muito da linguagem de programação utilizada.

Linguagens dinamicamente tipadas, como o Python por exemplo, não forçam qualquer tipo de implementação. Isso acontece devido ao fato de as declarações serem inferidas em tempo de execução.

Definição do ISP

Não trouxe nenhuma frase bonita escrita (ou dita) por alguma estrela da arquitetura de software, mas podemos definir e afirmar que:

A segregação de interface deve ser realizada sempre que um tipo/classe estiver sendo forçado a implementar um atributo e/ou um comportamento sem sentido e/ou sem propósito.

Vamos aos exemplos; se algo não estiver claro, a seção de aplicação consolida a ideia.

Violação do ISP

Podemos imaginar um cenário simples onde temos uma interface IPrinter que possui dois métodos: Print e Scan. Nosso programa possui duas classes que implementam essa interface, denominadas AdvancedPrinter e BasicPrinter.

A classe AdvancedPrinter pode imprimir e escanear documentos, e por isso implementa ambos os métodos. Já a classe BasicPrinter pode apenas imprimir documentos, portanto implementa apenas o método Print e lança uma exceção caso o método Scan seja acionado. Segue o código com este exemplo:

public record Document(string Name, string Content);

public interface IPrinter
{
    void Print(Document document);

    Document Scan();
}

public class AdvancedPrinter : IPrinter
{
    public void Print(Document) 
    {
        // Lógica para impressão do documento.
    }

    public Document Scan()
    {
        // Lógica para escanear um documento.
    }
}

public class BasicPrinter : IPrinter
{
    public void Print(Document) 
    {
        // Lógica para impressão do documento.
    }

    public Document Scan()
    {
        throw new NotImplementedException(
            "Esta impressora não pode escanear documentos.");
    }
}

Situações como esta são mais comuns do que parece e, em geral, indicam oportunidades de melhorar coesão e reduzir acoplamento.

Faz parte da evolução do time identificar esses casos e substituí-los por um desenho mais aderente ao domínio.

Mas se você ainda tem dúvidas do que deveria ser feito neste caso, não se preocupe! Este artigo foi escrito com muito carinho para ajudar pessoas como você! Pessoas que têm o brilho nos olhos e o interesse em construir códigos de qualidade.

Aplicação do ISP

Para ficar em conformidade com o Princípio da Segregação de Interface e resolver este problema é realmente muito simples!

Seguindo uma abordagem similar à utilizada no artigo sobre LSP, precisamos separar os comportamentos em interfaces distintas e implementá-las apenas quando forem realmente necessárias.

Sendo assim, podemos corrigir o exemplo apresentado há pouco da seguinte forma:

public record Document(string Name, string Content);

public interface IPrinter // Possui apenas o método de impressão.
{
    void Print(Document document);
}

public interface IScanner // Possui apenas o método de escaneamento.
{
    Document Scan();
}

public class AdvancedPrinter 
    : IPrinter, IScanner // Implementa ambas as interfaces.
{
    public void Print(Document) 
    {
        // Lógica para impressão do documento.
    }

    public Document Scan()
    {
        // Lógica para escanear um documento.
    }
}

public class BasicPrinter 
    : IPrinter // Implementa apenas a interface com método de impressão.
{
    public void Print(Document) 
    {
        // Lógica para impressão do documento.
    }
}

A abordagem é direta: lançar exceções ou criar métodos vazios apenas para cumprir uma interface é um antipadrão. Priorize coerência, durabilidade e longevidade do código.

Obrigado pela leitura.
Para aprofundar: Arquitetura Limpa — O Guia do Artesão para Estrutura e Design de Software (Robert C. Martin, 2019).

LSP - O Princípio da Substituição de Liskov

Thiago Souza — Thu, 09 Jan 2025 11:20:00 +0000

O LSP (Liskov Substitution Principle) é mais um dos 5 Princípios SOLID que todo bom programador e/ou arquiteto de software deveria conhecer. No entanto requer uma atenção especial pois ele é abstrato e mais difícil de entender, principalmente para quem está começando com SOLID.

Definição do LSP

Barbara Liskov, em maio de 1988, escreveu o seguinte texto para definir subtipos:

Se, para cada objeto o1 de tipo S, houver um objeto o2 de tipo T, de modo que, para todos os programas de tipo P não seja modificado quando o1 for substituído por o2, então S é um subtipo de T.

Sim! O nó no cérebro acontece de forma natural quando você tem o primeiro contato com esta definição. Mas não se desespere pois o texto escrito por Liskov pode ser simplificado e entendido como:

Sempre que o programa esperar receber uma instância de um tipo T, um subtipo S derivado de T deve poder substituí-lo sem que o programa precise de qualquer adequação para atender uma instância do subtipo S. Caso contrário, S não deveria ser um subtipo derivado de T.

Importante: ⚠️

👉 O LSP não se trata apenas de uma orientação sobre o uso da herança. Com o passar dos anos, o LSP se transformou em um princípio de design de software aplicável a qualquer tipo de interface e implementação.

👉 De forma mais abrangente, o segredo do sucesso é preservar as expectativas e garantir que o comportamento dos subtipos seja compatível com a intenção do tipo base.

Com esse resumo, podemos avançar.

Violação do LSP

Montei um exemplo em .NET C# (simples e para fins didáticos) que deve ajudar a entender uma das formas de violar o Princípio da Substituição de Liskov.

Observe com calma cada uma das classes:

public class Vehicle 
{
    public bool IsIgnitionOn { get; protected set; }

    public bool IsMoving { get; private set; }

    public virtual void StartIgnition()
    {
        this.IsIgnitionOn = true;
    }

    public void StartMove()
    { 
        this.IsMoving = true;
    }
}

public class Car : Vehicle
{
    public override void StartIgnition()
    {
        this.IsIgnitionOn = true;
    }
}

public class Motorcycle : Vehicle
{
    public override void StartIgnition()
    {
        this.IsIgnitionOn = true;
    }
}

public class Bicycle : Vehicle
{
    public override void StartIgnition()
    {
        throw new NotImplementedException();
    }
}

Agora vamos ver o que acontece quando executamos o método StartIgnition para diferentes instâncias de Vehicle:

public void StartVehicleIgnition(Vehicle vehicle)
{
    vehicle.StartIgnition();

    if (vehicle.IsIgnitionOn) 
    {
        Console.WriteLine(
            $"O veículo está com a ignição ligada.");
    }
}

StartVehicleIgnition(new Vehicle()); 
// ✅ O veículo está com a ignição ligada.

StartVehicleIgnition(new Car()); 
// ✅ O veículo está com a ignição ligada.

StartVehicleIgnition(new Motorcycle()); 
// ✅ O veículo está com a ignição ligada.

StartVehicleIgnition(new Bicycle()); 
// ❌ NotImplementedException

Neste caso fica evidente que, apesar de a bicicleta ser um veículo, no escopo deste programa, uma instância de Bicycle não consegue se adequar ao método StartIgnition e muito menos à propriedade IsIgnitionOn que representa um estado interno herdado da classe base Vehicle.

Alterar o programa, incluindo um tratamento de erro para atender única e exclusivamente uma ou mais instâncias de Bicycle, deveria ser considerado um crime.

Mas como eu sempre digo: Você não está aqui por acaso! A entropia do universo, de uma forma singular, te trouxe até aqui e agora você terá um bom exemplo para compartilhar com os seus colegas de trabalho para que eles também não cometam mais esse tipo erro.

Aplicação do LSP

Para corrigir e evitar que problemas como estes ocorram, poderiamos seguir com a seguinte abordagem:

public class Vehicle 
{
    public bool IsMoving { get; private set; }

    public void StartMove()
    {  
        this.IsMoving = true;
    }
}

public interface IVehicleMotorized 
{
    decimal IsIgnitionOn { get; }

    void StartIgnition();
}

public class Car : Vehicle, IVehicleMotorized 
{
    public decimal IsIgnitionOn { get; private set; }

    public void StartIgnition()
    {
        this.IsIgnitionOn = true;
    }
}

public class Motorcycle : Vehicle, IVehicleMotorized 
{
    public decimal IsIgnitionOn { get; private set; }

    public void StartIgnition()
    {
        this.IsIgnitionOn = true;
    }
}

public class Bicycle : Vehicle
{
    // Atributos e métodos específicos para bicicletas.
}

Neste caso criamos uma interface denominada IVehicleMotorized e fizemos as classes Car e Motorcycle implementarem as propriedades e comportamentos da nossa nova abstração.

Quanto à classe Vehicle, removemos tudo o que não pode ser utilizado em bicicletas e deixamos apenas comportamentos/métodos que estejam diretamente relacionados com o que chamamos de veículos no escopo deste programa.

Vamos refatorar o trecho onde utilizamos o método StartIgnition e a propriedade IsIgnitionOn para garantir que apenas classes que implementem a interface IVehicleMotorized possam ser acionadas no método StartVehicleIgnition:

public void StartVehicleIgnition(IVehicleMotorized  vehicle)
{
    vehicle.StartIgnition();

    if (vehicle.IsIgnitionOn) 
    {
        Console.WriteLine(
            $"O veículo está com a ignição ligada.");
    }
}

StartVehicleIgnition(new Car()); 
// ✅ O veículo está com a ignição ligada.

StartVehicleIgnition(new Motorcycle()); 
// ✅ O veículo está com a ignição ligada.

Para concluir, vamos criar um programa de exemplo onde nenhum comportamento inesperado acontece ao realizar a substituição da classe base Vehicle por qualquer uma das outras classes derivadas:

public void StartMoveVehicle(Vehicle vehicle)
{
    vehicle.StartMove();

    if (vehicle.IsMoving) {
        Console.WriteLine("O veículo está em movimento.");
    }
}

StartMoveVehicle(new Vehicle()); 
// ✅ O veículo está em movimento.

StartMoveVehicle(new Car()); 
// ✅ O veículo está em movimento.

StartMoveVehicle(new Motorcycle()); 
// ✅ O veículo está em movimento.

StartMoveVehicle(new Bicycle()); 
// ✅ O veículo está em movimento.

Encerramos por aqui.

Como mencionado, este foi um exemplo de uma dentre outras formas de violação deste princípio. A discussão pode ser extensa e vale aprofundar conforme o contexto do seu sistema.

Se você já presenciou violações do LSP, documente os casos e seus impactos para orientar decisões futuras.

Obrigado pela leitura.
Para aprofundar: Arquitetura Limpa — O Guia do Artesão para Estrutura e Design de Software (Robert C. Martin, 2019).

OCP - O Princípio Aberto/Fechado

Thiago Souza — Mon, 06 Jan 2025 10:50:00 +0000

O OCP (Open/Closed Principle) é um dos 5 Princípios SOLID que todo bom programador e/ou arquiteto de software deveria conhecer. A aplicação do Princípio da Responsabilidade Única é extremamente importante para que possamos separar as classes que podem mudar por razões diferentes e vai nos ajudar muito na implementação do Princípio Aberto/Fechado.

Definição do OCP

Este princípio pode ser definido através da seguinte frase:

"Um artefato de software deve estar aberto para extensão e fechado para modificação."

Em outras palavras, o principal objetivo deste princípio é fazer com que o nosso sistema possa receber modificações através de extensões sem que novas solicitações de mudança possam eventualmente nos forçar a realizar alterações no software todo.

Cenários como esse são comuns em bases de código em evolução.

Violação do OCP

Aqui temos um exemplo muito simples criado apenas para fins didáticos e, pensando em uma API, vamos começar criando nossos endpoints para download de um relatório em PDF e outro em CSV:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Endpoint para retornar PDF
app.MapGet("/download/pdf", async () =>
{
    var reportGenerator = new ReportGenerator();

    var bytes = reportGenerator.Generate(new ReportContent(), ReportType.PDF);

    return Results.File(bytes, "application/pdf", "xpto.pdf");
});

// Endpoint para retornar CSV
app.MapGet("/download/csv", () =>
{
    var reportGenerator = new ReportGenerator();

    var bytes = reportGenerator.Generate(new ReportContent(), ReportType.CSV);

    return Results.File(csvBytes, "text/csv", "xpto.csv");
});

app.Run();

Para que o código das nossas classes não fiquem muito extensos, use a sua imaginação para visualizar o conteúdo das classes ReportContent e ReportGenerator:

public class ReportContent
{
    // Atributos referente ao conteúdo do relatório
}

public enum ReportType 
{
    PDF = 1,
    CSV = 2
}

public class ReportGenerator
{
    public byte[] Generate(ReportContent reportContent, ReportType reportType)
    {
        if (reportType == ReportType.PDF)
        {
            // Lógica para gerar o relatório PDF
        }
        else
        {
           // Lógica para gerar o relatório CSV
        }
    }
}

Como podemos ver neste exemplo de código, a classe ReportGenerator recebe dois parâmetros. Um deles (ReportContent) é o conteúdo que será utilizado para compor o relatório e o outro (ReportType) indica qual o tipo de relatório desejado pelo usuário/ator.

O cenário está armado para que, sempre que surgir um novo tipo de relatório, seja necessário incluir novas condições nesta classe. Pode acontecer ainda (e acontece muito) de todas as dependencias necessárias para cada tipo de relatório estarem sendo importadas no mesmo arquivo, deixando o corpo desta classe ainda mais complexo e com baixa coesão.

Mas nem tudo está perdido, pois este artigo está aqui para te ajudar a resolver e evitar este tipo de problema.

Aplicando o OCP

Considerando o código do exemplo anterior, vamos começar removendo o enum ReportType pois ele não será mais necessário. Além disso vamos criar uma interface denominada IReportGenerator com a assinatura do método Generate e que recebe apenas a classe que representa o conteúdo do nosso relatório como parâmetro.

public class ReportContent
{
    // Atributos referente ao conteúdo do relatório
}

public interface IReportGenerator
{
    byte[] Generate(ReportContent reportContent);
}

Feito isto, vamos criar uma classe para cada tipo de relatório e ambas devem implementar a nossa nova interface e aplicar a lógica necessária para gerar o relatório.

public class PdfReportGenerator : IReportGenerator
{
    public byte[] Generate(ReportContent reportContent)
    {
        // Lógica para gerar o relatório PDF
    }
}

public class CsvReportGenerator : IReportGenerator
{
    public byte[] Generate(ReportContent reportContent)
    {
        // Lógica para gerar o relatório CSV
    }
}

Agora vamos criar um classe chamada ReportService e ela precisa receber a nossa abstração (interface) como parâmetro em seu construtor:

public class ReportService(IReportGenerator reportGenerator)
{
    public byte[] GenerateReport(ReportContent reportContent)
    {
        return reportGenerator.Generate(reportContent);
    }
}

Vamos finalizar atualizando o código dos nossos endpoints:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Endpoint para retornar PDF
app.MapGet("/download/pdf", async () =>
{
    var reportService = new ReportService(new PdfReportGenerator());

    var bytes = reportService.GenerateReport(new ReportContent());

    return Results.File(bytes, "application/pdf", "xpto.pdf");
});

// Endpoint para retornar CSV
app.MapGet("/download/csv", () =>
{
    var reportService = new ReportService(new CsvReportGenerator());

    var bytes = reportService.GenerateReport(new ReportContent());

    return Results.File(csvBytes, "text/csv", "xpto.csv");
});

app.Run();

Com isto, qualquer novo tipo de relatório não irá forçar você e os seus colegas desenvolvedores a realizarem alterações de ponta a ponta no software, pois a implementação de uma nova extensão é mais do que suficiente.

Ainda não está convencido? Vamos implementar agora um relatório XLSX:

// Nova classe referente ao tipo de arquivo XLSX
public class XlsxReportGenerator : IReportGenerator
{
    public byte[] Generate(ReportContent reportContent)
    {
        // Lógica para gerar o relatório XLSX
    }
}

//--

// Novo endpoint para retornar XLSX
app.MapGet("/download/xslx", () =>
{
    var reportService = new ReportService(new XlsxReportGenerator());

    var bytes = reportService.GenerateReport(new ReportContent());

    return Results.File(bytes, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "xpto.xlsx");
});

Implementação concluída.

Essa é a essência do OCP: classes que geram relatórios ficam fechadas para modificações e o software permanece aberto a novas extensões.

Reflita sobre como aplicar esse princípio no seu contexto.

Obrigado pela leitura.
Para aprofundar: Arquitetura Limpa — O Guia do Artesão para Estrutura e Design de Software (Robert C. Martin, 2019).

SRP - O Princípio da Responsabilidade Única

Thiago Souza — Fri, 03 Jan 2025 05:16:26 +0000

Segundo o próprio Robert C. Martin (Uncle Bob), o SRP (Single Responsibility Principle) é com certeza, de todos os 5 Princípios SOLID, o menos compreendido. Sinto em ter que dizer isto, mas ele está certo.

O que vou apresentar aqui não é apenas uma opinião, mas sim o meu entendimento baseado na definição que o próprio criador deste conjunto de princípios desejava passar como mensagem quando publicou o seu artigo.

Definição do SRP

Sem mais delongas, vou agora te apresentar a frase que melhor define o Princípio da Responsabilidade Única:

"Um módulo deve ser responsável por um, e apenas um, ator."

É isso mesmo. Ele define um módulo como um arquivo fonte e, dependendo da linguagem de programação, um módulo pode ser definido como um conjunto coeso de funções e estrutura de dados. Em C#, por exemplo, podemos entender esta definição de módulo como uma classe.

Violação do SRP

A duplicidade de código é algo que todo bom desenvolvedor tenta evitar e por isso criamos métodos com trechos de código que podem ser reaproveitados.

Quando escrevemos um método com trechos de código contendo parte de uma regra de negócio que pode atender mais de um ator, devemos ter um pouco mais de cautela e cuidado para entender se isso não pode nos gerar um problema.

Vamos imaginar um cenário (hipotético) onde:

O ator do departamento de Vendas calcula o valor do desconto de um pedido;
O ator do departamento Financeiro calcula o valor da comissão a ser paga sobre um pedido;

public class Pedido 
{
    public List<ItemPedido> Itens { get; set; }

    // Método utilizado pelo ator do departamento de Vendas
    public decimal CalcularDesconto(decimal percentualDeconto)
    {
        decimal valorTotal = CalcularValorTotal();

        decimal desconto = valorTotal * percentualDeconto;

        return desconto;
    }

    // Método utilizado pelo ator do departamento Financeiro
    public decimal CalcularComissao(decimal percentualComissao)
    {
        decimal valorTotal = CalcularValorTotal();

        decimal comissao = valorTotal * percentualComissao;

        return comissao;
    }

    // Método privado compartilhado entre os métodos 
    // CalcularImposto e CalcularComissao
    private decimal CalcularValorTotal()
    {
        decimal valorTotal = Itens.Sum(item => item.Valor);

        return valorTotal;
    }
}

Independentemente se esses métodos estão em uma única classe ou alocados cada um em uma classe específica, esta tentativa de reaproveitamento de código faz com que os atores responsáveis pelo Financeiro e Vendas fiquem acoplados um ao outro, pois qualquer alteração na função CalcularValorTotal atinge diretamente os métodos utilizados pelos dois atores.

Digamos que em algum momento futuro o ator do departamento de Vendas decida que não quer mais considerar itens do tipo Premium no cálculo de descontos. O desenvolvedor prontamente decide incluir um filtro antes de somar os itens no método CalcularValorTotal, sobe as alterações para o ambiente de homologação e pede para o ator do departamento de Vendas validar a alteração antes de subir para produção.

O ator do departamento de Vendas realiza todos os testes minuciosamente e indica que está tudo OK. Por fim, o desenvolvedor faz o deploy no ambiente de produção e finaliza a Change Request.

Dias (ou semanas) depois, alguém descobre que essa alteração quebrou o cálculo de comissão gerando um enorme problema para o ator do departamento Financeiro.

Isso por que nem fomos muito longe falando, por exemplo, sobre possíveis problemas no processo de merge das branches de outros desenvolvedores da equipe.

Tenho certeza que você já consegue imaginar a criticidade e o motivo pelo qual devemos evitar que atores estejam acoplados uns aos outros.

Dependendo do seu tempo na área de desenvolvimento, me arrisco a dizer que, muito provavelmente você já tenha vivenciado algum tipo de situação como esta.

Mas o destino quis que você chegasse até este ponto da leitura e agora você tem o poder nas mãos de simplificar o processo de desenvolvimento de software para você e todos os seus colegas de trabalho, evitando o famoso "arruma de um lado e estraga de outro".

Aplicando o SRP

Existem várias formas de evitar (e solucionar) este problema. Pensando a longo prazo e na saúde do software, poderiamos organizar o código da seguinte forma:

// Entidade de Pedido
public class Pedido 
{
    public List<ItemPedido> Itens { get; set; }
}

// Classe específica para o calculo de desconto de um pedido
// exclusiva para o ator do departamento de Vendas
public class ProvedorCalculoDescontoPedido(Pedido pedido)
{
    public decimal Calcular(decimal percentualDesconto)
    {
        decimal total = pedido.Itens.Sum(item => item.Valor);

        decimal desconto = total * percentualDeconto;

        return desconto;
    }
}

// Classe específica para o cálculo de comissão de um pedido
// exclusiva para o ator do departamento Financeiro
public class ProvedorCalculoComissaoPedido(Pedido pedido)
{
    public decimal Calcular(decimal percentualComissao)
    {
        decimal total = pedido.Itens
            .Where(item => item.Tipo != TipoItemPedido.Premium)
            .Sum(item => item.Valor);

        decimal comissao = total * percentualComissao;

        return comissao ;
    }
}

À partir de agora, qualquer nova solicitação de mudança realizada por qualquer um dos atores, não deverá mais gerar os problemas relatados anteriormente. Além disso, as classes ficam mais coesas e passam a ser responsáveis por um, e apenas um, ator — reduzindo acoplamento entre atores e facilitando manutenção.

Obrigado pela leitura.
Para aprofundar: Arquitetura Limpa — O Guia do Artesão para Estrutura e Design de Software (Robert C. Martin, 2019).