Arquitetura antes do código: como planejar te faz codificar com confiança

Rafael de Lima — Mon, 24 Mar 2025 23:59:54 +0000

"O código perfeito não nasce do acaso, mas de um plano bem estruturado"
Durante meus estudos, algumas imersões, descobri que a maior revolução no desenvolvimento não está nas linhas de código, mas no planejamento estratégico que as antecede. Neste artigo, vou detalhar como organizar ideias, definir problemas e desenhar arquiteturas antes de codificar transformou um projeto simples (um sistema de cadastro de eventos) em uma experiência de aprendizado estruturada e eficiente.

Índice

Antes do Código: A Arte de Definir o Problema
Organizando ideias: Do caos à Clareza
Desenhando a Arquitetura: O Blueprint do Projeto
Codificando com Propósito: Do Diagrama à Prática
Lições Aprendidas (e Como Você Pode Aplicar)
Conclusão: Por que Planejar Vale a Pena?
Bônus: Checklist Pré-Codificação

1. Antes do Código: A Arte de Definir o Problema

Muitos desenvolvedores que estão iniciando na carreira pulam esta etapa, mas é aqui que a mágica começa.

Escreva o problema claramente:

Exemplo: "Preciso de um sistema para cadastrar eventos, com datas, locais e participantes, garantindo que os dados sejam persistidos e acessíveis via API."
Isso evita escopo aberto e direciona as decisões técnicas.

Liste requisitos funcionais e não funcionais:

Funcionais: Cadastro de eventos, integração com banco de dados, endpoints REST.

Não funcionais: Performance (resposta em < 2s), segurança (autenticação futura), escalabilidade.

Valide com stakeholders:

Mesmo em projetos pessoais, simule perguntas como: "O que é essencial para a versão 1.0?"

2. Organizando Ideias: Do Caos à Clareza

Antes de abrir o IDE, organize suas ideias em camadas.

Separe responsabilidades:

Frontend: Interface do usuário.

Backend: Lógica de negócio, APIs.

Banco de Dados: Modelagem de tabelas.

Use ferramentas visuais (Draw.io/FigJam):

No projeto, desenhamos um diagrama com:

Isso ajudou a visualizar o fluxo de dados e como estruturar minhas pastas antes mesmo de codificar.

3. Desenhando a Arquitetura: O Blueprint do Projeto

Aqui entra o Spring Boot, mas com propósito!

Spring Boot vs Spring Framework:

Spring Boot: Foco em configuração automática (embedded Tomcat, starters),

Spring Framework: Controle manual de dependências (ideal para projetos complexos).

Camadas da aplicação (em detalhes):

1.Controller:

Responsável por receber requisições HTTP.

Anotações: @RestController, @RequestMapping

2.Service:

Lógica de negócio (validações, regras).

Anotação: @Service.

3.Repository:

Comunicação com o banco (JPA/Hibernate).

Anotação: @Repository

4.Model:

Entidades do banco (ex: Evento com id, nome, data).

MySQL + JPA:

Configuração simplificada via application.properties.
User @Querypara consultas personalizadas.

4. Codificando com Propósito: Do Diagrama à Prática

Com o plano pronto, codificar virou execução, não adivinhação.

Exemplo de fluxo:

// Model
@Table(name = "tbl_event")
@Entity
public class Event {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "event_id")
    private Integer eventId;

    @Column(name = "title", length = 255, nullable = false)
    private String title;
    @Column(name = "pretty_name", length = 50, nullable = false, unique = true)
    private String prettyName;
    @Column(name = "location", length = 255, nullable = false)
    private String location;

    @Column(name = "price", nullable = false)
    private Double price;

    @Column(name = "start_date")
    private LocalDate startDate;
    @Column(name = "end_date")
    private LocalDate endDate;

    @Column(name = "start_time")
    private LocalTime startTime;
    @Column(name = "end_time")
    private LocalTime endTime;


// Repository
public interface EventRepository extends CrudRepository<Event, Integer> {

    public Event findByPrettyName(String prettyName);
}

// Service
@Service
public class EventService {

    @Autowired
    private EventRepository eventRepository;

    public Event addNewEvent(Event event) {
        event.setPrettyName(event.getTitle().toLowerCase().replaceAll(" ", "-"));
        return eventRepository.save(event);
    }

    public List<Event> getAllEvents() {
        return (List<Event>) eventRepository.findAll();
    }

    public Event getEventByPrettyName(String prettyName) {
        return eventRepository.findByPrettyName(prettyName);
    }
}

// Controller
@RestController
public class EventController {

    @Autowired
    private EventService eventService;

    @PostMapping("/events")
    public Event addNewEvent(@RequestBody Event newEvent) {
        return eventService.addNewEvent(newEvent);
    }

    @GetMapping("/events")
    public List<Event> getAllEvents() {
        return eventService.getAllEvents();
    }

    @GetMapping("/events/{prettyName}")
    public ResponseEntity<Event> getEventByPrettyName(@PathVariable String prettyName) {
        Event event = eventService.getEventByPrettyName(prettyName);
        if (event != null) {
            return ResponseEntity.ok().body(event);
        }
        return ResponseEntity.notFound().build();
    }
}

5. Lições Aprendidas (e Como Você Pode Aplicar)

Documente decisões técnicas:
Crie um README.md com porquês (ex: "Escolhemos Spring Boot para agilizar a configuração").
Refatore sem medo:
O planejamento reduziu retrabalho, mas ajustes são normais. Ex: otimizamos queries após analisar logs.
Ferramentas que salvam:

Draw.io para diagramas

Postman para testar APIs durante o desenvolvimento

6. Conclusão: Por que Planejar Vale a Pena?

Planejar a arquitetura e organizar ideias não é "perda de tempo" – é ganho de eficiência. No projeto, evitamos:

Classes "Deus" (com responsabilidades demais).

Acoplamento excessivo entre camadas.

Surpresas na integração com o banco.

E você? Já usou alguma técnica de planejamento que mudou sua forma de codar? Compartilhe nos comentários! 👇

7. Bônus: Checklist Pré-Codificação

Defina o problema por escrito.
Liste requisitos funcionais e não funcionais.
Desenhe a arquitetura (fluxo de dados e camadas).
Escolha tecnologias com base no escopo.
Documente decisões técnicas.

DEV Community: Rafael de Lima