DEV Community: Ximena Soto

Armando un Sistema de E-Commerce con DDD, Java y Algunos Tropiezos Épicos

Ximena Soto — Thu, 17 Jul 2025 02:48:40 +0000

Imagina esto: un desarrollador de Java, un teclado, y la loca idea de construir algo genial con Domain-Driven Design (DDD). Esa soy yo, lanzándome de cabeza a DddEcommerceOrders, un sistema de e-commerce que es mitad ambición, mitad cafeína, y un toque de “¿por qué no funciona esto?”. Este proyecto, alojado en https://github.com/xsoto-developer/DddEcommerceOrders, es mi patio de juegos para dominar Java, Spring Boot y microservicios, con un guiño a mis primeros pasos en DevOps y mi aventura hacia AWS. Prepárate, geeks tecnológicos, porque voy a contarte los aciertos, desaciertos y momentos de comedia de este viaje, con la esperanza de encender tu curiosidad y sacarte una sonrisa.

El Gran Plan: Crear un Imperio de E-Commerce (Más o Menos)

Quise construir DddEcommerceOrders, un sistema basado en microservicios para gestionar pedidos e inventario en una tienda online imaginaria. Piensa en “Amazon, pero codedado por una soñadora en pijama que ama DDD”. El proyecto se divide en dos microservicios:

orders-service: Maneja el caos de crear pedidos, confirmar pagos y cancelarlos cuando alguien pide 500 suéteres para gatos por error.
inventory-service: Controla el stock, porque vender laptops imaginarios no es buen negocio.

Cada microservicio sigue una arquitectura limpia—Dominio, Aplicación, Infraestructura—porque me gusta complicarme la vida con estilo. Está construido con Java 17, Spring Boot 3.2.0, y un toque de magia DDD para mantener todo en orden.

¿Qué Hay en la Caja?

Líos de Pedidos: Crear pedidos, confirmar pagos y cancelarlos cuando el cliente se arrepiente de su obsesión por los suéteres felinos.
Magia de Inventario: Reservar stock al confirmar pedidos, usando eventos de dominio para no vender cosas que no existen.
Swagger con Actitud: Documentación interactiva de APIs en /swagger-ui.html—porque presionar botones para probar endpoints es puro amor.
Pruebas a Tope: Tests unitarios con JUnit 5 para que mi código no se desmorone como galleta en café.
CI/CD con Estilo: Un pipeline de GitHub Actions que compila y prueba como jefe, mostrando mis primeros coqueteos con DevOps.

El Baile DDD: Pasos Bien Dados y Algún Pisotón

DDD es como coreografiar un baile entre la lógica de negocio y el código, y yo aún estoy aprendiendo a no pisarme los pies. DddEcommerceOrders se divide en dos Bounded Contexts:

Gestión de Pedidos:
- Protagonista: El agregado Pedido, haciendo malabares con LineaDePedido (artículos) y Direccion (dónde enviar esos suéteres para gatos).
- Frases Pegajosas: “Confirmar pedido”, “cancelar pedido”—mi código habla el mismo idioma que el negocio.
- Truco Estelar: Lanza un OrderConfirmedEvent para gritarle al servicio de inventario, “¡Oye, reserva stock!”
Gestión de Inventario:
- Estrella Principal: El agregado Producto, con su fiel compañero Stock.
- Palabras Clave: “Reservar stock”, “liberar stock”—porque un almacén vacío es pura tristeza.
- Modo Ninja: Escucha el OrderConfirmedEvent para actualizar el stock sin hacer ruido.

Aquí tienes un vistazo al Bounded Context de Gestión de Pedidos, dibujado en Mermaid porque soy así de extra:

classDiagram
    class Pedido {
        -UUID id
        -List~LineaDePedido~ lineas
        -Direccion direccionEnvio
        -EstadoPedido estado
        -Double montoPago
        +confirmarPago(monto: double)
        +cancelar()
        +getId(): UUID
    }
    class LineaDePedido {
        -UUID productoId
        -int cantidad
        -double precioUnitario
    }
    class Direccion {
        -String calle
        -String ciudad
        -String codigoPostal
    }
    class EstadoPedido {
        <<enumeration>>
        PENDIENTE
        CONFIRMADO
        ENVIADO
        CANCELADO
    }
    Pedido o--> "many" LineaDePedido
    Pedido --> "1" Direccion
    Pedido --> "1" EstadoPedido

Los Detalles Techies: Donde Brillamos (y Tropezamos)

Java y Spring Boot: Mis Fieles Compinches

Con Java 17 y Spring Boot 3.2.0, construí un sistema robusto pero con personalidad. Algunos highlights:

Arquitectura Limpia: Manteniendo la lógica de dominio pura, lejos del caos de la infraestructura.
Base de Datos H2: Una base en memoria porque aún no estoy listo para pelear con bases de datos de producción.
Swagger con Drama: Añadí Swagger para documentar APIs, sintiéndome un genio… hasta que no funcionó (sigue leyendo).
Eventos de Dominio: Usé ApplicationEventPublisher de Spring para que los microservicios charlen sin ponerse pegajosos.

DevOps a Media Máquina

Soy un novato en DevOps, pero configuré un pipeline de GitHub Actions para compilar, probar y lucir mis habilidades CI/CD. Es como enseñarle a un robot a revisar mi tarea—bastante genial cuando funciona.

Sueños con AWS

El proyecto corre localmente, pero estoy estudiando para certificaciones AWS. Pronto desplegaré esta bestia en la nube, tal vez en ECS o EKS, para demostrar que puedo jugar en las grandes ligas.

Los Momentos “Facepalm”: Aprendiendo a Puro Golpe

El camino del coder es una mezcla de “¡Eureka!” y “¿Por qué, universo, por qué?”. Aquí van mis mejores tropiezos:

Swagger Rebelde: Añadí Swagger con orgullo, solo para que me mirara con un “No operations defined in spec!”. Resulta que mis controladores jugaban al escondite con Springdoc. Un @Tag y algo de logging DEBUG los pusieron en su lugar.
Fiesta Vacía en H2: Intenté reservar stock con curl y me dio un “Producto no encontrado”. Mi base H2 estaba más vacía que mi taza de café a las 3 de la mañana. Un script data.sql con productos dummy salvó el día.
DDD Sobrepensado: Pasé horas debatiendo si Stock debía ser una entidad o un value object. Spoiler: Es un value object, y me compliqué la vida por nada.

Estos deslices me enseñaron a abrazar el caos, depurar como detective, y reírme cuando mi código decide tomarse un descanso.

¡Pruébalo, Coder Valiente!

¿Listo para meterte en este lío? Explora DddEcommerceOrders en https://github.com/xsoto-developer/DddEcommerceOrders. Aquí va cómo arrancar:

Clona el repo:

   git clone https://github.com/xsoto-developer/DddEcommerceOrders.git

Lanza los microservicios:

   cd orders-service
   mvn clean install
   mvn spring-boot:run
   cd ../inventory-service
   mvn clean install
   mvn spring-boot:run

Juega con Swagger:
- Pedidos: http://localhost:8080/swagger-ui.html
- Inventario: http://localhost:8081/swagger-ui.html
Espía en H2:
- Ve a http://localhost:8081/h2-console (JDBC URL: jdbc:h2:mem:inventorydb, User: sa, Password: vacío).
- Corre SELECT * FROM PRODUCTO; para fisgonear el stock.

Consejo pro: Si Swagger se pone rebelde, revisa los logs de org.springdoc o dale un buen mvn clean install para calmarlo.

¿Qué Sigue para Este Domador de Código?

Estoy enganchado a programar y aprender, así que esto es lo que viene:

Aventura AWS: Desplegar este proyecto en AWS para mostrar que puedo domar la nube.
DevOps a Fondo: Más Docker, Kubernetes, y tal vez Terraform para darle sabor.
Líos Open-Source: Contribuir a proyectos para unirme a la fiesta global de coders.

¡Hagamos Travesuras Tecnológicas!

¿Tienes algo que decir sobre DddEcommerceOrders? ¿Te gustó el diagrama UML? ¿Odias mi obsesión con suéteres para gatos? Pásate por https://github.com/xsoto-developer/DddEcommerceOrders, pruébalo y comparte tu sabiduría. Si eres un techie o reclutador buscando un entusiasta de Java/DDD/DevOps con talento para aprender (y algún que otro facepalm), ¡charlemos—estoy listo para construir algo épico!

Gracias por acompañarme en esta montaña rusa de código. Sigue hackeando, sigue riendo, ¡y no pidas 500 suéteres para gatos!

Este artículo también está disponible en: Inglés

Hacking Together an E-Commerce System with DDD, Java, and a Few Facepalms

Ximena Soto — Thu, 17 Jul 2025 02:28:33 +0000

Picture this: a Java developer, a keyboard, and a dream of building something cool with Domain-Driven Design (DDD). That’s me, diving headfirst into DddEcommerceOrders, an e-commerce system that’s equal parts ambition, caffeine, and “why isn’t this working?!” moments. This project, hosted at https://github.com/xsoto-developer/DddEcommerceOrders, is my playground for mastering Java, Spring Boot, and microservices, with a sprinkle of DevOps and a nod to my ongoing AWS adventure. Buckle up, tech nerds, as I share the highs, lows, and hilarious missteps of building this beast, hoping to spark your curiosity and maybe a chuckle or two.

The Grand Plan: Building an E-Commerce Empire (Sort Of)

I set out to create DddEcommerceOrders, a microservices-based system to manage orders and inventory for an imaginary e-commerce empire. Think “Amazon, but coded by one guy in pajamas with a love for DDD.” The project splits into two microservices:

orders-service: Handles the chaos of order creation, payment confirmation, and cancellations.
inventory-service: Keeps track of stock, because nobody wants to sell 100 imaginary laptops that don’t exist.

Each microservice follows a clean architecture—Domain, Application, Infrastructure—because I’m fancy like that. It’s built with Java 17, Spring Boot 3.2.0, and a dash of DDD magic to keep things organized.

What’s Inside the Box?

Order Shenanigans: Create orders, confirm payments, and cancel them when someone inevitably orders 500 cat sweaters by mistake.
Inventory Wizardry: Reserve stock when orders are confirmed, using domain events to avoid awkward overselling situations.
Swagger Swagger: Interactive API docs at /swagger-ui.html—because who doesn’t love clicking buttons to test APIs?
Tests, Tests, Tests: JUnit 5 unit tests to make sure my code doesn’t implode.
CI/CD Coolness: A GitHub Actions pipeline that builds and tests like a boss, proving I’m dipping my toes into DevOps.

The DDD Dance: Twirling Through Bounded Contexts

DDD is like choreographing a dance between business logic and code, and I’m still learning the steps. DddEcommerceOrders splits into two Bounded Contexts:

Order Management:
- Star of the Show: The Pedido aggregate, juggling LineaDePedido (items) and Direccion (where to ship those cat sweaters).
- Catchy Phrases: “Confirm order,” “cancel order”—my code speaks the same language as the business.
- Party Trick: Fires an OrderConfirmedEvent to tell the inventory service, “Yo, reserve some stock!”
Inventory Management:
- Main Character: The Producto aggregate, with its trusty sidekick Stock.
- Buzzwords: “Reserve stock,” “release stock”—because nobody likes an empty warehouse.
- Listener Vibes: Catches OrderConfirmedEvent to update stock like a ninja.

Here’s a peek at the Order Management Bounded Context, drawn in Mermaid because I’m extra:

classDiagram
    class Pedido {
        -UUID id
        -List~LineaDePedido~ lineas
        -Direccion direccionEnvio
        -EstadoPedido estado
        -Double montoPago
        +confirmarPago(monto: double)
        +cancelar()
        +getId(): UUID
    }
    class LineaDePedido {
        -UUID productoId
        -int cantidad
        -double precioUnitario
    }
    class Direccion {
        -String calle
        -String ciudad
        -String codigoPostal
    }
    class EstadoPedido {
        <<enumeration>>
        PENDIENTE
        CONFIRMADO
        ENVIADO
        CANCELADO
    }
    Pedido o--> "many" LineaDePedido
    Pedido --> "1" Direccion
    Pedido --> "1" EstadoPedido

The Techy Bits: Where I Shined (and Tripped)

Java and Spring Boot: My Trusty Sidekicks

Using Java 17 and Spring Boot 3.2.0, I built a system that’s robust but not boring. Some highlights:

Clean Architecture: Keeping domain logic pure, away from the messy infrastructure stuff.
H2 Database: An in-memory database because I’m not ready to wrestle with production-grade DBs just yet.
Swagger Shenanigans: Added Swagger for API docs, which made me feel like a rockstar… until it didn’t work (more on that later).
Domain Events: Used Spring’s ApplicationEventPublisher to keep microservices chatty without them getting clingy.

DevOps Dabbling

I’m a newbie to DevOps, but I set up a GitHub Actions pipeline to build, test, and flex my CI/CD muscles. It’s like teaching a robot to check my homework—pretty cool when it works!

AWS Dreams

The project runs locally, but I’m prepping for AWS certifications. Soon, I’ll deploy this bad boy to the cloud, maybe on ECS or EKS, to show I can play in the big leagues.

The Facepalm Moments: Learning the Hard Way

Every coder’s journey is a mix of “Eureka!” and “Why, universe, why?” Here are my top bloopers:

Swagger’s Silent Treatment: I proudly added Swagger, only to see “No operations defined in spec!” staring back at me. Turns out, my controllers were playing hide-and-seek with Springdoc. A quick @Tag and some DEBUG logging later, they were back in the spotlight.
H2’s Empty Party: Tried reserving stock with curl, got “Producto no encontrado.” Cue me realizing my H2 database was emptier than my coffee mug at 3 AM. A data.sql script with some dummy products saved the day.
DDD Overthinking: I spent hours debating whether Stock should be an entity or a value object. Spoiler: It’s a value object, and I overcomplicated it for no reason.

These missteps taught me to embrace the chaos, debug like a detective, and laugh when my code decides to take a coffee break.

Try It Out, You Curious Coder!

Ready to dive into the madness? Check out DddEcommerceOrders at https://github.com/xsoto-developer/DddEcommerceOrders. Here’s how to get it running:

Clone the repo:

   git clone https://github.com/xsoto-developer/DddEcommerceOrders.git

Fire up the microservices:

   cd orders-service
   mvn clean install
   mvn spring-boot:run
   cd ../inventory-service
   mvn clean install
   mvn spring-boot:run

Play with Swagger:
- Orders: http://localhost:8080/swagger-ui.html
- Inventory: http://localhost:8081/swagger-ui.html
Snoop around H2:
- Hit http://localhost:8081/h2-console (JDBC URL: jdbc:h2:mem:inventorydb, User: sa, Password: blank).
- Run SELECT * FROM PRODUCTO; to spy on the stock.

Pro tip: If Swagger gives you attitude, check the logs for org.springdoc or give your server a good ol’ restart (mvn clean install never hurts).

What’s Next for This Code Wrangler?

I’m hooked on coding and learning, so here’s what’s on my radar:

AWS Adventure: Deploying this project to AWS to prove I can tame the cloud.
DevOps Deep Dive: More Docker, Kubernetes, and maybe some Terraform to spice things up.
Open-Source Shenanigans: Contributing to projects to join the global coder party.

Let’s Geek Out Together!

Got thoughts on DddEcommerceOrders? Loved the UML diagram? Hated my cat sweater obsession? Drop by https://github.com/xsoto-developer/DddEcommerceOrders, give it a spin, and share your wisdom. If you’re a fellow techie or a recruiter looking for a Java/DDD/DevOps enthusiast with a knack for learning (and occasional facepalms), let’s chat—I’m ready to build something epic!

Thanks for joining me on this coding rollercoaster. Keep hacking, keep laughing, and maybe don’t order 500 cat sweaters!

This article is also available in: Spanish

From Monolith to Microservices

Ximena Soto — Sun, 13 Apr 2025 16:18:49 +0000

Building a Resilient Hotel Booking System with Spring Boot and Resilience4j

As a seasoned Java developer, I’ve always been fascinated by the challenge of building systems that are not just functional but also scalable, resilient, and maintainable. Over the years, I’ve worked on various projects, but none have been as transformative as my recent journey into microservices with the Hotel Reservation System—a project that pushed me to embrace 3 resilience patterns (Circuit Breaker + Retry) for hotel bookings, with polyglot persistence (PostgreSQL + MongoDB). In this article, I’ll share the technical and personal lessons learned while transitioning from a monolithic mindset to a microservices architecture, focusing on the challenges, triumphs, and practical insights for Java developers looking to make a similar leap.

Introduction: A Java Developer’s Quest for Resilience

With experience in Java, I’ve built everything from enterprise monoliths to RESTful APIs. But as cloud-native architectures gained traction, I felt the urge to dive into microservices—not just to stay relevant but to explore how patterns like Circuit Breaker, Retry, and Specification could elevate system design. My motivation was clear: create a hotel booking platform that could handle real-world failures gracefully, using modern tools like Spring Boot 3.2.4, Maven, PostgreSQL, MongoDB, Resilience4j, and Swagger/OpenAPI.

The Hotel Reservation System became my playground—a set of three microservices (hotel-rooms-service, hotel-reservations-service, and hotel-payments-service) designed to manage room availability, reservations, and payments. This project wasn’t just about coding; it was about mastering design patterns, embracing polyglot persistence, and deploying with Docker. Along the way, I faced significant challenges, learned invaluable lessons, and even had a few humbling moments that reshaped my approach to development.

The Challenges: Navigating the Microservices Maze

Transitioning to microservices wasn’t a walk in the park. Here are the key obstacles I encountered and the lessons they taught me:

Challenge 1: Understanding Microservices Boundaries

Coming from a monolithic background, I initially struggled to define clear boundaries for each microservice. Should payments handle reservation validation? Should rooms manage availability checks? The complexity of distributed systems felt overwhelming.

Learning: I adopted Domain-Driven Design (DDD) principles to carve out bounded contexts. For example, hotel-rooms-service focused solely on room inventory and availability, using the Specification Pattern to filter rooms dynamically:

public List<Room> findAvailableRooms(Integer guestCount, Double maxPrice) {
    Specification<Room> spec = Specification.where(RoomSpecifications.isAvailable())
        .and(RoomSpecifications.hasGuestCapacity(guestCount))
        .and(RoomSpecifications.hasMaxPrice(maxPrice));
    return roomRepository.findAll(spec);
}

This pattern encapsulated filtering logic, making it reusable and testable—a cornerstone of clean code in microservices.

Challenge 2: Resilience in a Distributed World

Failures in microservices are inevitable—network glitches, database timeouts, or third-party service outages. My early attempts at payment processing were brittle, crashing on transient errors.

Learning: I embraced 3 resilience patterns (Circuit Breaker + Retry) for hotel bookings using Resilience4j. The payment service became my proving ground:

@CircuitBreaker(name = "paymentService", fallbackMethod = "processPaymentFallback")
@Retry(name = "paymentService", fallbackMethod = "processPaymentFallback")
public Payment processPayment(String reservationId, double amount) {
    logger.info("Processing payment for reservationId: {}", reservationId);
    if (Math.random() > 0.7) {
        throw new RuntimeException("Payment service failed");
    }
    Payment payment = new Payment(UUID.randomUUID().toString(), reservationId, amount, "COMPLETED");
    return paymentRepository.save(payment);
}

public Payment processPaymentFallback(String reservationId, double amount, Throwable t) {
    logger.warn("Fallback triggered for reservationId: {} due to: {}", reservationId, t.getMessage());
    return new Payment(UUID.randomUUID().toString(), reservationId, amount, "PENDING");
}

CircuitBreaker: Prevents cascading failures by opening the circuit after 5 failures (50% of 10 calls), redirecting to the fallback.
Retry: Attempts up to 3 retries with exponential backoff (500ms, 1000ms, 2000ms) before giving up.
Configuration (in application.properties):

  resilience4j.circuitbreaker.instances.paymentService.slidingWindowSize=10
  resilience4j.circuitbreaker.instances.paymentService.failureRateThreshold=50
  resilience4j.retry.instances.paymentService.maxAttempts=3
  resilience4j.retry.instances.paymentService.waitDuration=500
  resilience4j.retry.instances.paymentService.enableExponentialBackoff=true

This combination made the payment service robust, handling transient failures gracefully while maintaining user trust with a "PENDING" status.

Challenge 3: Polyglot Persistence

Using PostgreSQL for rooms and reservations and MongoDB for payments introduced complexity. I underestimated the differences in data modeling and connection management.

Learning: Polyglot persistence requires careful planning. For example, hotel-rooms-service used JPA for structured room data:

@Entity
public class Room {
    @Id
    private String id;
    private String type;
    private int guestCapacity;
    private double price;
    private boolean available;
    // Getters and setters
}

Meanwhile, hotel-payments-service leveraged MongoDB’s flexibility:

@Document(collection = "payments")
public class Payment {
    @Id
    private String id;
    private String reservationId;
    private double amount;
    private String status;
    // Getters and setters
}

I learned to align database choices with domain needs—PostgreSQL for relational integrity, MongoDB for high-write scenarios like payments.

Challenge 4: Dockerizing a Multi-Module Project

Deploying with Docker revealed my naivety about multi-module Maven projects. My first Dockerfile attempts failed spectacularly, with errors like:

ERROR: failed to solve: maven:3.9.6-openjdk-17: not found

and later:

[FATAL] Non-resolvable parent POM for org.xsoto.springcloud.msvc:hotel-payments-service:0.0.1-SNAPSHOT

Learning: Multi-stage Docker builds and proper context management are critical. Here’s the final Dockerfile for hotel-payments-service:

# Stage 1: Build the application
FROM maven:3.9.6-eclipse-temurin-17 AS builder
WORKDIR /app
COPY ../pom.xml ./pom.xml
COPY ./pom.xml ./hotel-payments-service/pom.xml
RUN mvn dependency:go-offline -B
COPY src ./hotel-payments-service/src
RUN mvn clean package -pl hotel-payments-service -am -DskipTests

# Stage 2: Create the runtime image
FROM openjdk:17-jdk-alpine
WORKDIR /app
COPY --from=builder /app/hotel-payments-service/target/hotel-payments-service-1.0-SNAPSHOT.jar app.jar
EXPOSE 8083
ENV SPRING_DATA_MONGODB_URI=mongodb://mongo:27017/payments_db
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

The key was including the parent pom.xml and building from the root directory to resolve dependencies.

A Personal Anecdote: The Docker Debacle

Let me share a moment that humbled me. Early in the Dockerization process, I was confident I could whip up a Dockerfile in minutes. I started with maven:3.8.6-openjdk-17-slim, assuming it existed. Spoiler: it didn’t. The build failed with image not found. Undeterred, I switched to maven:3.9.6-openjdk-17—another dead end. Then came the real kicker: the Non-resolvable parent POM error. I’d overlooked the multi-module structure, naively copying only the module’s pom.xml.

Hours of debugging later, I realized my mistake: Docker’s build context needed the parent pom.xml, and I had to verify image tags on Docker Hub. It was a classic case of overconfidence meeting reality. But that frustration led to a breakthrough—learning to use multi-stage builds, .dockerignore, and docker-compose effectively. That moment taught me to respect the nuances of containerization and double-check assumptions.

Practical Experience: Bringing It All Together

Building the Hotel Reservation System required integrating Spring Boot 3.2.4, Maven, PostgreSQL, MongoDB, Resilience4j, and Swagger/OpenAPI. Here’s how it came together:

Microservices Setup:
- hotel-rooms-service (port 8081, PostgreSQL): Manages room inventory with the Specification Pattern.
- hotel-reservations-service (port 8082, PostgreSQL): Handles bookings with a Factory Pattern for object creation.
- hotel-payments-service (port 8083, MongoDB): Processes payments with CircuitBreaker + Retry.
Docker Compose:

A single docker-compose.yml orchestrated everything:

  version: '3.8'
  services:
    postgres:
      image: postgres:15-alpine
      environment:
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: password
      ports:
        - "5432:5432"
    mongo:
      image: mongo:6
      ports:
        - "27017:27017"
    hotel-rooms-service:
      build:
        context: .
        dockerfile: hotel-rooms-service/Dockerfile
      ports:
        - "8081:8081"
      environment:
        SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/rooms_db
    hotel-reservations-service:
      build:
        context: .
        dockerfile: hotel-reservations-service/Dockerfile
      ports:
        - "8082:8082"
      environment:
        SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/reservations_db
    hotel-payments-service:
      build:
        context: .
        dockerfile: hotel-payments-service/Dockerfile
      ports:
        - "8083:8083"
      environment:
        SPRING_DATA_MONGODB_URI: mongodb://mongo:27017/payments_db

Swagger/OpenAPI:
Each service exposed a Swagger UI (e.g., http://localhost:8083/swagger-ui.html), making API testing a breeze.
Testing:
Comprehensive tests validated resilience patterns:

  @Test
  void testProcessPayment_FallbackTriggered() {
      String reservationId = "res1";
      double amount = 150.0;
      circuitBreaker.transitionToOpenState();
      Payment result = paymentService.processPayment(reservationId, amount);
      assertEquals("PENDING", result.getStatus());
  }

Tips for Java Developers Transitioning to Microservices

For fellow Java developers eyeing a similar transition, here are practical tips to make your journey smoother:

Master Design Patterns:
- Study Circuit Breaker, Retry, and Specification. They’re not just buzzwords—they solve real problems. Start with Resilience4j’s documentation for hands-on examples.
- Example: Tune Retry parameters carefully to avoid overwhelming downstream services.
Embrace Polyglot Persistence:
- Choose databases based on domain needs. For our hotel system, PostgreSQL ensured relational integrity for rooms, while MongoDB handled high-write payment data.
- Tip: Use Spring Data’s abstractions to simplify repository code across databases.
Get Comfortable with Docker:
- Use multi-stage builds to keep images lean. Alpine-based images like openjdk:17-jdk-alpine saved me ~200 MB per service.
- Always verify image tags on Docker Hub before building.
- Example: .dockerignore is your friend:
```
 target/
 *.jar
 *.log
 .idea/
```
Test Relentlessly:
- Write tests for resilience patterns. Mock failures to ensure fallbacks work as expected.
- Use tools like JaCoCo for code coverage to impress potential employers.

Automate Early:

Set up a CI/CD pipeline (e.g., GitHub Actions) to build and test Docker images automatically. This saves time and catches errors early.
Example: A simple workflow to build and push images:

 name: Build Docker Images
 on: [push]
 jobs:
   build:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
       - run: docker-compose build

Learn from Mistakes:
- Don’t fear errors like image not found or non-resolvable POM. They’re opportunities to deepen your understanding.
- Keep a debugging log to track what worked and what didn’t.

Conclusion: A Journey Worth Taking

Transitioning to microservices with the Hotel Reservation System was a game-changer. It taught me to build resilient, scalable systems using 3 resilience patterns (Circuit Breaker + Retry) for hotel bookings, with polyglot persistence (PostgreSQL + MongoDB). The challenges—defining boundaries, mastering resilience, and conquering Docker—were steep but rewarding. Each error, from missing image tags to POM resolution woes, sharpened my skills and mindset.

To my fellow Java developers: dive into microservices and design patterns. Experiment with Spring Boot, Resilience4j, and Docker. The road may be bumpy, but the ability to craft systems that thrive under pressure is worth every moment. Start small, test rigorously, and automate fearlessly. Your next project could be the one that defines your career.

🔍 ¿Would you like to see the code in action?

Explore SpringResilientHotel on GitHub:

👉 github.com/xsoto-developer/SpringResilientHotel

What’s your next microservices adventure? Share your thoughts in the comments or ping me on GitHub!

✨ Bonus: Feel free to leave a ⭐️ or open an issue with suggestions, I appreciate the feedback!

This article is also available in: Spanish

De Monolitos a Microservicios

Ximena Soto — Sun, 13 Apr 2025 15:50:30 +0000

Construyendo un Sistema de Reservas de Hotel Resiliente con Spring Boot y Resilience4j

Como desarrollador Java, siempre me ha apasionado construir sistemas que no solo funcionen, sino que también sean escalables, resilientes y fáciles de mantener. He trabajado en proyectos de todo tipo, desde monolitos empresariales hasta APIs RESTful, pero ninguno ha sido tan transformador como mi incursión en microservicios con el Sistema de Reservas de Hotel. Este proyecto me permitió dominar 3 patrones de resiliencia (Circuit Breaker + Retry) para reservas hoteleras, con persistencia políglota (PostgreSQL + MongoDB). En este artículo, comparto los retos, aprendizajes y consejos prácticos para desarrolladores Java experimentados que quieran embarcarse en una transición similar hacia microservicios, con un enfoque en patrones de diseño y resiliencia.

Introducción: La Búsqueda de Resiliencia de un Desarrollador Java

Con algunos años de experiencia en Java, he construido sistemas robustos, pero el auge de las arquitecturas nativas en la nube me motivó a explorar los microservicios. Quería ir más allá de lo convencional y aprender cómo los patrones de diseño como Circuit Breaker, Retry y Specification podían elevar la calidad de mis aplicaciones. Mi objetivo fue ambicioso: desarrollar un sistema de reservas hoteleras que manejara fallos del mundo real con elegancia, utilizando herramientas modernas como Spring Boot 3.2.4, Maven, PostgreSQL, MongoDB, Resilience4j y Swagger/OpenAPI.

El Sistema de Reservas de Hotel se convirtió en mi laboratorio personal, compuesto por tres microservicios: hotel-rooms-service (gestión de habitaciones), hotel-reservations-service (reservas) y hotel-payments-service (pagos). Este proyecto no solo se trató de programar, sino de adoptar una mentalidad distribuida, integrar persistencia políglota y desplegar con Docker. A lo largo del camino, enfrenté desafíos significativos, aprendí lecciones valiosas y viví momentos que me hicieron replantear mi enfoque como desarrollador.

Los Retos: Navegando por el Laberinto de los Microservicios

La transición a microservicios no fue sencilla. Aquí detallo los principales obstáculos que encontré y las lecciones que me dejaron:

Reto 1: Definir los Límites de los Microservicios

Proveniente de un entorno monolítico, me costó delimitar las responsabilidades de cada microservicio. ¿Debería el servicio de pagos validar reservas? ¿El servicio de habitaciones debería gestionar la disponibilidad? La complejidad de los sistemas distribuidos me abrumó al principio.

Aprendizaje: Adopté principios de Diseño Dirigido por el Dominio (DDD) para establecer contextos acotados. Por ejemplo, hotel-rooms-service se centró únicamente en el inventario de habitaciones, utilizando el Patrón Specification para filtrar disponibilidad de forma dinámica:

public List<Room> findAvailableRooms(Integer guestCount, Double maxPrice) {
    Specification<Room> spec = Specification.where(RoomSpecifications.isAvailable())
        .and(RoomSpecifications.hasGuestCapacity(guestCount))
        .and(RoomSpecifications.hasMaxPrice(maxPrice));
    return roomRepository.findAll(spec);
}

Este patrón encapsuló la lógica de filtrado, haciéndola reutilizable y fácil de probar, un pilar del código limpio en microservicios.

Reto 2: Resiliencia en un Mundo Distribuido

Los fallos en microservicios son inevitables: problemas de red, tiempos de espera en bases de datos o caídas de servicios externos. Mis primeros intentos de procesar pagos eran frágiles, colapsando ante errores transitorios.

Aprendizaje: Implementé patrones de resiliencia (Circuit Breaker + Retry) para reservas hoteleras con Resilience4j. El servicio de pagos fue mi campo de pruebas:

@CircuitBreaker(name = "paymentService", fallbackMethod = "processPaymentFallback")
@Retry(name = "paymentService", fallbackMethod = "processPaymentFallback")
public Payment processPayment(String reservationId, double amount) {
    logger.info("Procesando pago para reservationId: {}", reservationId);
    if (Math.random() > 0.7) {
        throw new RuntimeException("Fallo en el servicio de pagos");
    }
    Payment payment = new Payment(UUID.randomUUID().toString(), reservationId, amount, "COMPLETED");
    return paymentRepository.save(payment);
}

public Payment processPaymentFallback(String reservationId, double amount, Throwable t) {
    logger.warn("Fallback activado para reservationId: {} debido a: {}", reservationId, t.getMessage());
    return new Payment(UUID.randomUUID().toString(), reservationId, amount, "PENDING");
}

CircuitBreaker: Evita fallos en cascada al abrir el circuito tras 5 errores (50% de 10 llamadas), redirigiendo al fallback.
Retry: Reintenta hasta 3 veces con backoff exponencial (500ms, 1000ms, 2000ms) antes de rendirse.
Configuración (en application.properties):

  resilience4j.circuitbreaker.instances.paymentService.slidingWindowSize=10
  resilience4j.circuitbreaker.instances.paymentService.failureRateThreshold=50
  resilience4j.retry.instances.paymentService.maxAttempts=3
  resilience4j.retry.instances.paymentService.waitDuration=500
  resilience4j.retry.instances.paymentService.enableExponentialBackoff=true

Esta combinación hizo que el servicio de pagos fuera robusto, manejando fallos transitorios sin comprometer la experiencia del usuario.

Reto 3: Persistencia Políglota

Usar PostgreSQL para habitaciones y reservas y MongoDB para pagos añadió complejidad. Subestimé las diferencias en modelado de datos y gestión de conexiones.

Aprendizaje: La persistencia políglota requiere planificación. Por ejemplo, hotel-rooms-service usó JPA para datos estructurados:

@Entity
public class Room {
    @Id
    private String id;
    private String type;
    private int guestCapacity;
    private double price;
    private boolean available;
    // Getters y setters
}

En cambio, hotel-payments-service aprovechó la flexibilidad de MongoDB:

@Document(collection = "payments")
public class Payment {
    @Id
    private String id;
    private String reservationId;
    private double amount;
    private String status;
    // Getters y setters
}

Aprendí a alinear la elección de bases de datos con las necesidades del dominio: PostgreSQL para integridad relacional, MongoDB para escenarios de alta escritura como pagos.

Reto 4: Dockerizando un Proyecto Multi-Módulo

Desplegar con Docker expuso mi falta de experiencia con proyectos Maven multi-módulo. Mis primeros intentos fallaron estrepitosamente, con errores como:

ERROR: failed to solve: maven:3.9.6-openjdk-17: not found

y más tarde:

[FATAL] Non-resolvable parent POM for org.xsoto.springcloud.msvc:hotel-payments-service:0.0.1-SNAPSHOT

Aprendizaje: Los builds multi-stage y la gestión del contexto son cruciales. Este es el Dockerfile final para hotel-payments-service:

# Stage 1: Build the application
FROM maven:3.9.6-eclipse-temurin-17 AS builder
WORKDIR /app
COPY ../pom.xml ./pom.xml
COPY ./pom.xml ./hotel-payments-service/pom.xml
RUN mvn dependency:go-offline -B
COPY src ./hotel-payments-service/src
RUN mvn clean package -pl hotel-payments-service -am -DskipTests

# Stage 2: Create the runtime image
FROM eclipse-temurin:17.0.10_7-jre-alpine
WORKDIR /app
COPY --from=builder /app/hotel-payments-service/target/hotel-payments-service-1.0-SNAPSHOT.jar app.jar
EXPOSE 8083
ENV SPRING_DATA_MONGODB_URI=mongodb://mongo:27017/payments_db
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

La clave fue incluir el pom.xml padre y construir desde el directorio raíz para resolver dependencias.

Una Anécdota Personal: El Desastre con Docker

Permíteme contarte un momento que me hizo más humilde. Al principio del proceso de dockerización, estaba convencido de que crear un Dockerfile sería pan comido. Empecé con maven:3.8.6-openjdk-17-slim, asumiendo que existía. No fue así—el build falló con image not found. Cambié a maven:3.9.6-openjdk-17, pero el error persistió. Luego, el golpe final: el temido Non-resolvable parent POM. Había ignorado la estructura multi-módulo, copiando solo el pom.xml del módulo.

Tras horas de depuración, descubrí mi error: el contexto de Docker necesitaba el pom.xml padre, y debía verificar los tags en Docker Hub. Fue un recordatorio doloroso de no dar nada por sentado. Pero esa frustración me llevó a dominar builds multi-stage, .dockerignore y docker-compose. Ese traspié me enseñó a valorar los detalles de la contenerización.

Experiencia Práctica: Uniendo las Piezas

Construir el Sistema de Reservas de Hotel requirió integrar Spring Boot 3.2.4, Maven, PostgreSQL, MongoDB, Resilience4j y Swagger/OpenAPI. Así lo logré:

Configuración de Microservicios:
- hotel-rooms-service (puerto 8081, PostgreSQL): Gestiona inventario con Patrón Specification.
- hotel-reservations-service (puerto 8082, PostgreSQL): Maneja reservas con Patrón Factory.
- hotel-payments-service (puerto 8083, MongoDB): Procesa pagos con CircuitBreaker + Retry.
Docker Compose:

Un único docker-compose.yml orquestó todo:

  version: '3.8'
  services:
    postgres:
      image: postgres:15-alpine
      environment:
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: password
      ports:
        - "5432:5432"
    mongo:
      image: mongo:6
      ports:
        - "27017:27017"
    hotel-rooms-service:
      build:
        context: .
        dockerfile: hotel-rooms-service/Dockerfile
      ports:
        - "8081:8081"
      environment:
        SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/rooms_db
    hotel-reservations-service:
      build:
        context: .
        dockerfile: hotel-reservations-service/Dockerfile
      ports:
        - "8082:8082"
      environment:
        SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/reservations_db
    hotel-payments-service:
      build:
        context: .
        dockerfile: hotel-payments-service/Dockerfile
      ports:
        - "8083:8083"
      environment:
        SPRING_DATA_MONGODB_URI: mongodb://mongo:27017/payments_db

Swagger/OpenAPI:
Cada servicio expuso una interfaz Swagger (por ejemplo, http://localhost:8083/swagger-ui.html), facilitando pruebas de APIs.
Pruebas:
Tests exhaustivos validaron los patrones de resiliencia:

  @Test
  void testProcessPayment_FallbackTriggered() {
      String reservationId = "res1";
      double amount = 150.0;
      circuitBreaker.transitionToOpenState();
      Payment result = paymentService.processPayment(reservationId, amount);
      assertEquals("PENDING", result.getStatus());
  }

Consejos para Desarrolladores Java en Transición

Para los desarrolladores Java que quieran dar el salto a microservicios, aquí van algunos consejos prácticos:

Domina los Patrones de Diseño:
- Aprende Circuit Breaker, Retry y Specification. No son solo teoría—resuelven problemas reales. Explora la documentación de Resilience4j para ejemplos prácticos.
- Consejo: Ajusta los parámetros de Retry con cuidado para no saturar servicios externos.
Adopta la Persistencia Políglota:
- Elige bases de datos según el dominio. En nuestro sistema, PostgreSQL aseguró integridad para habitaciones, mientras MongoDB manejó datos de pagos de alta escritura.
- Usa abstracciones de Spring Data para simplificar el código de repositorios.
Familiarízate con Docker:
- Usa builds multi-stage para imágenes ligeras. Las imágenes Alpine como eclipse-temurin:17.0.10_7-jre-alpine me ahorraron ~200 MB por servicio.
- Verifica siempre los tags en Docker Hub antes de construir.
- Ejemplo: Un .dockerignore bien configurado:
```
 target/
 *.jar
 *.log
 .idea/
```
Prueba sin Descanso:
- Escribe tests para patrones de resiliencia. Simula fallos para validar fallbacks.
- Usa herramientas como JaCoCo para medir cobertura y destacar tu trabajo.

Automatiza desde el Inicio:

Configura un pipeline CI/CD (por ejemplo, GitHub Actions) para construir y probar imágenes Docker automáticamente.
Ejemplo: Un flujo básico para construir imágenes:

 name: Build Docker Images
 on: [push]
 jobs:
   build:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
       - run: docker-compose build

Aprende de los Errores:
- No temas a errores como image not found o non-resolvable POM. Son oportunidades para crecer.
- Lleva un registro de depuración para documentar qué funcionó y qué no.

Conclusión: Un Viaje que Vale la Pena

La transición a microservicios con el Sistema de Reservas de Hotel cambió mi perspectiva como desarrollador. Me enseñó a construir sistemas resilientes y escalables usando 3 patrones de resiliencia (Circuit Breaker + Retry) para reservas hoteleras, con persistencia políglota (PostgreSQL + MongoDB). Los retos—definir límites, dominar resiliencia y superar Docker—fueron duros pero gratificantes. Cada error, desde tags de imágenes inexistentes hasta problemas con el POM, afinó mis habilidades y mentalidad.

A mis colegas desarrolladoras y desarrolladores Java: sumérjanse en los microservicios y los patrones de diseño. Experimenten con Spring Boot, Resilience4j y Docker. El camino puede ser accidentado, pero la capacidad de crear sistemas que prosperen bajo presión vale cada esfuerzo. Empiecen pequeño, prueben rigurosamente y automaticen sin miedo. Su próximo proyecto podría definir su carrera.

🔍 ¿Te gustaría ver el código en acción?

Explora SpringResilientHotel en GitHub:

👉 github.com/xsoto-developer/SpringResilientHotel

¿Cuál será tu próxima aventura en microservicios? ¡Comparte tus ideas en los comentarios o contáctame en GitHub!

✨ Bonus: Siéntete libre de dejar una ⭐️ o abrir un issue con sugerencias. ¡Aprecio el feedback!

Este artículo también está disponible en: Inglés

The Importance of Clean Code

Ximena Soto — Sun, 13 Apr 2025 03:21:46 +0000

An Analysis of CleanTechAPI in Java and .NET

Software development isn’t just about making things work—it’s about doing it right. Clean Code is a philosophy that prioritizes readability, maintainability, and scalability. In one of my projects, CleanTechAPI, I applied these principles to both Java (with Spring Boot) and C# (with .NET 8). Both are REST APIs for managing a catalog of futuristic gadgets, but they’re designed with distinct approaches: one for experienced developers and the other with a more intuitive focus. In this article, we’ll explore why clean code matters, how it’s reflected in the codebase, and the similarities and differences between these two technologies.

Why Is Clean Code Important?

Clean code isn’t a luxury—it’s a necessity. Well-written software reduces errors, eases collaboration, and saves time in the long run. For CleanTechAPI, I relied on principles like YAGNI (You Aren’t Gonna Need It), KISS (Keep It Simple, Stupid), DRY (Don’t Repeat Yourself), and SOLID to ensure the code is:

Readable: Understandable at a glance.
Maintainable: Easy to modify without breaking everything.
Scalable: Ready to grow without becoming chaotic.

These principles not only make my life as a developer easier but are also standards valued by architects and tech leads in real-world projects.

CleanTechAPI: Two Approaches, One Goal

JavaCleanTechAPI (Spring Boot)

Purpose: Demonstrate a professional-grade REST API with Spring Boot, targeting advanced developers and architects.
Features: Uses Clean Architecture, Maven, an in-memory H2 database, and Swagger for documentation. Includes an engaging endpoint (/products/trending) featuring futuristic gadgets like the "Quantum X Drone."

AspCleanTechAPI (.NET 8)

Purpose: Teach developers how to build a REST API with a more intuitive approach using C# and .NET 8, leveraging its integrated tooling and simplicity.
Features: Implements Entity Framework Core (InMemory), Visual Studio as the IDE, and Newtonsoft.Json for streamlined serialization. Retains the same engaging endpoint but adapts it for accessibility.

Both projects share a common core: applying clean code to solve a practical, interesting use case.

How Is Clean Code Reflected in These Projects?

Clean code isn’t just theory—it’s visible in concrete decisions. Here are some examples:

1. Separation of Concerns (SOLID - SRP)

Java:

  @RestController
  @RequestMapping("/products")
  public class ProductController {
      private final ProductService service;

      @Autowired
      public ProductController(ProductService service) {
          this.service = service;
      }

      @GetMapping
      public List<Product> getAll() {
          return service.getAllProducts();
      }
  }

The controller only handles HTTP requests, delegating logic to the service layer.
- C#:

  [ApiController]
  [Route("products")]
  public class ProductController : ControllerBase
  {
      private readonly ProductService _service;
      public ProductController(ProductService service) => _service = service;

      [HttpGet]
      public ActionResult<List<Product>> GetAll() => Ok(_service.GetAllProducts());
  }

Similar to Java, the controller is lightweight, with logic residing in ProductService.

2. Descriptive, Self-Documenting Names (KISS)

Both use names like Product, ProductService, and getAllProducts, which explain their purpose without redundant comments.

3. Avoiding Duplication (DRY)

Java: Data access logic is centralized in ProductRepository using Spring Data JPA.
C#: ProductService reuses EF Core’s context for all operations.

4. Simplicity (YAGNI)

Neither project includes unnecessary features like authentication, keeping the focus on the product catalog.

Similarities Between Java and .NET in CleanTechAPI

Despite different languages and frameworks, both projects share:

Structure: Follow Clean Architecture with clear layers (models/domain, services/application, controllers/infrastructure).
Dependency Injection: Decouples components seamlessly.
Persistence: Use in-memory databases (H2 and EF Core InMemory) for simplicity.
Documentation: Integrate Swagger for exploring endpoints like /products and /products/trending.
Engaging Purpose: Both feature a futuristic use case to capture attention.

Key Differences Between Java and .NET

While the goal is the same, the implementations reflect each technology’s philosophy:

Dependency Injection

Spring Boot (Java):
- Uses @Autowired for automatic dependency injection via Spring’s IoC container.
- Example:
```
@Autowired
private ProductService service;
```
- More "magic" and flexible but requires understanding annotations.
ASP.NET Core (C#):
- Explicitly registers services with IServiceCollection in Program.cs.
- Example:
```
builder.Services.AddScoped<ProductService>();
```
And in the controller:
```
public ProductController(ProductService service) => _service = service;
```
- More transparent and direct, leveraging .NET’s native integration.

Other Differences

Audience: Java targets professionals; .NET offers a more intuitive approach.
Tools: Maven vs. .NET CLI; IntelliJ IDEA vs. Visual Studio.
Serialization: Jackson (Java) is automatic; .NET requires tweaks (e.g., Newtonsoft.Json).
Complexity: Java is more verbose/configurable; .NET is more integrated/accessible.

Conclusion

Clean code is the heart of CleanTechAPI, whether in Java or .NET. Both projects prove that principles like SOLID and DRY aren’t language-dependent—they’re about how we structure solutions. Java offers power and flexibility for complex projects, while .NET shines with its intuitive, streamlined approach. Ultimately, the goal is to write code that not only works but also inspires and is easy to maintain.

Want to see how it’s done? Check out the projects on GitHub:

JavaCleanTechAPI: https://github.com/xsoto-developer/spring-clean-tech-api
AspCleanTechAPI: https://github.com/xsoto-developer/asp-clean-tech-api

Explore, learn, and share your thoughts!

This article is also available in: Spanish

La importancia del código limpio

Ximena Soto — Wed, 09 Apr 2025 20:27:27 +0000

Un análisis de CleanTechAPI en Java y .NET

El desarrollo de software no solo se trata de hacer que las cosas funcionen, sino de hacerlo bien. El código limpio (Clean Code) es una filosofía que prioriza la legibilidad, mantenibilidad y escalabilidad del código, y en uno de mis proyectos, CleanTechAPI, he aplicado estos principios tanto en Java con Spring Boot como en C# con .NET 8. Ambos son APIs REST para gestionar un catálogo de gadgets futuristas, pero están diseñados con enfoques distintos: uno para desarrolladores experimentados y otro con un enfoque más intuitivo. En este artículo, exploraremos por qué el código limpio importa, cómo se refleja en el código y las similitudes y diferencias entre estas dos tecnologías.

¿Por qué el código limpio es importante?

El código limpio no es un lujo, es una necesidad. Un software bien escrito reduce errores, facilita la colaboración y ahorra tiempo a largo plazo. En CleanTechAPI, me basé en principios como YAGNI (You Aren’t Gonna Need It), KISS (Keep It Simple, Stupid), DRY (Don’t Repeat Yourself) y SOLID para asegurar que el código sea:

Legible: Cualquiera puede entenderlo con un vistazo.
Mantenible: Fácil de modificar sin romper todo.
Escalable: Preparado para crecer sin volverse un caos.

Estos principios no solo hacen mi vida más fácil como desarrollador, sino que también son un estándar que los arquitectos y líderes técnicos valoran en proyectos reales.

CleanTechAPI: Dos enfoques, un mismo objetivo

JavaCleanTechAPI (Spring Boot)

Finalidad: Mostrar un ejemplo profesional de una API REST con Spring Boot, dirigido a desarrolladores avanzados y arquitectos.
Características: Usa Clean Architecture, Maven, base de datos H2 en memoria y Swagger para documentación. Incluye un endpoint atractivo (/products/trending) con gadgets futuristas como "Drone Quantum X".

AspCleanTechAPI (.NET 8)

Finalidad: Enseñar a desarrolladores cómo construir una API REST con un enfoque más intuitivo en C# usando .NET 8, aprovechando su integración y simplicidad.
Características: Implementa Entity Framework Core con InMemory, Visual Studio como IDE y Newtonsoft.Json para facilitar la serialización. Mantiene el mismo endpoint atractivo adaptado a una experiencia accesible.

Ambos proyectos comparten un núcleo común: aplicar código limpio para resolver un caso de uso interesante y práctico.

¿Dónde se ve el código limpio en estos proyectos?

El código limpio no es solo teoría; se refleja en decisiones concretas dentro del código. Aquí algunos ejemplos:

1. Separación de responsabilidades (Principio SOLID - SRP)

Java:

  @RestController
  @RequestMapping("/products")
  public class ProductController {
      private final ProductService service;

      @Autowired
      public ProductController(ProductService service) {
          this.service = service;
      }

      @GetMapping
      public List<Product> getAll() {
          return service.getAllProducts();
      }
  }

El controlador solo maneja solicitudes HTTP, delegando la lógica al servicio.
- C#:

  [ApiController]
  [Route("products")]
  public class ProductController : ControllerBase
  {
      private readonly ProductService _service;
      public ProductController(ProductService service) => _service = service;

      [HttpGet]
      public ActionResult<List<Product>> GetAll() => Ok(_service.GetAllProducts());
  }

Similar al Java, el controlador es ligero y la lógica vive en ProductService.

2. Nombres descriptivos y auto-documentados (KISS)

Ambos usan nombres como Product, ProductService y getAllProducts, que explican su propósito sin comentarios redundantes.

3. Evitar duplicación (DRY)

Java: La lógica de acceso a datos está centralizada en ProductRepository con Spring Data JPA.
C#: ProductService reutiliza el contexto de EF Core para todas las operaciones.

4. Simplicidad (YAGNI)

Ningún proyecto incluye autenticación o funcionalidades complejas innecesarias, manteniendo el foco en el catálogo de productos.

Similitudes entre Java y .NET en CleanTechAPI

A pesar de usar lenguajes y frameworks distintos, ambos proyectos comparten:

Estructura: Siguen Clean Architecture con capas claras (modelos/dominio, servicios/aplicación, controladores/infraestructura).
Inyección de dependencias: Facilitan el desacoplamiento entre componentes.
Persistencia: Usan bases de datos en memoria para simplicidad (H2 y EF Core InMemory).
Documentación: Integran Swagger para explorar endpoints como /products y /products/trending.
Propósito atractivo: Ambos destacan con un caso de uso futurista que capta la atención.

Diferencias clave entre Java y .NET

Aunque el objetivo es el mismo, las implementaciones reflejan las filosofías de cada tecnología:

Inyección de dependencias

Spring Boot (Java):
- Usa @Autowired para inyectar dependencias automáticamente mediante el contenedor IoC de Spring.
- Ejemplo:
```
@Autowired
private ProductService service;
```
- Es más "mágico" y flexible, pero requiere entender las anotaciones.
ASP.NET Core (C#):
- Registra servicios explícitamente con IServiceCollection en Program.cs.
- Ejemplo:
```
builder.Services.AddScoped<ProductService>();
```
Y en el controlador:
```
public ProductController(ProductService service) => _service = service;
```
- Más transparente y directo, aprovechando la integración nativa de .NET.

Otras diferencias

Audiencia: Java apunta a profesionales; .NET ofrece un enfoque más intuitivo.
Herramientas: Maven vs. .NET CLI; IntelliJ IDEA vs. Visual Studio.
Serialización: Jackson (Java) es automático; .NET requiere ajustes (como usar Newtonsoft.Json).
Complejidad: Java es más verboso y configurable; .NET es más integrado y accesible.

Conclusión

El código limpio es el corazón de CleanTechAPI, ya sea en Java o .NET. Ambos proyectos demuestran que principios como SOLID y DRY no dependen del lenguaje, sino de cómo estructuramos nuestras soluciones. Java ofrece potencia y flexibilidad para proyectos complejos, mientras que .NET destaca por su enfoque intuitivo y su integración simplificada. Al final, lo importante es escribir código que no solo funcione, sino que inspire y sea fácil de mantener.

¿Quieres ver cómo lo hice? Revisa los proyectos en GitHub:

JavaCleanTechAPI: https://github.com/xsoto-developer/spring-clean-tech-api
AspCleanTechAPI: https://github.com/xsoto-developer/asp-clean-tech-api

¡Explora, aprende y comparte tus pensamientos!

Este artículo también está disponible en: Inglés

Mi Viaje de Desarrollador Java a Ingeniero DevOps

Ximena Soto — Mon, 07 Apr 2025 02:37:25 +0000

Desafíos y Aprendizajes Clave 🚀

Después de años trabajando como desarrollador backend con Java y Spring Boot, decidí dar un paso adelante hacia el mundo de DevOps. En este artículo comparto los retos, errores, aprendizajes y herramientas que marcaron mi transición hacia esta nueva etapa profesional.

🛠️ Desde conceptos básicos de CI/CD, Docker y Kubernetes hasta la integración con Jenkins, Helm y ArgoCD — todo contado desde mi experiencia real.

📄 Puedes leer el artículo completo aquí 👉 Mi Viaje de Desarrollador Java a Ingeniero DevOps

👨‍💻 Si estás considerando dar el salto a DevOps, espero que este artículo te inspire y te ahorre algunos tropiezos.

¡Gracias por leer! Me encantaría saber qué opinas en los comentarios 🙌