Stop writing boilerplate: Building a Java CLI for Clean Architecture

Mohamed Mabrouk — Fri, 08 May 2026 23:16:38 +0000

Setting up a proper Spring Boot Clean Architecture is, frankly, a war crime against developer productivity.

Before you can write a single line of business logic, you spend hours creating domain entities, use cases, controller interfaces, DTOs, and mapper configurations across 30+ different files. It's tedious, it's error-prone, and it leads to massive inconsistencies across engineering teams.

Friction is the enemy of velocity. So, I decided to automate it.

Enter ArchiGen

I built ArchiGen: a CLI tool that generates full Spring Boot Clean Architecture projects in less than 5 seconds.

Why Pure Java and PicoCLI?

When building developer tooling, speed and control are everything. I could have used a heavy framework or a scripting language, but I wanted a compiled, robust tool.

I chose pure Java combined with PicoCLI. PicoCLI is incredibly lightweight and allows for the creation of elegant, UNIX-style command-line interfaces with minimal overhead.

How It Works Under the Hood

To generate the boilerplate, ArchiGen doesn't just copy-paste empty text files. It uses FreeMarker, a powerful templating engine.

When you run the command to generate a new microservice, ArchiGen takes your specific domain inputs, feeds them into **FreeMarker **templates, and dynamically builds out the entire layered architecture.

// A conceptual look at how ArchiGen processes templates
Template template = cfg.getTemplate("UseCase.ftl");
Map<String, Object> data = new HashMap<>();
data.put("domainName", userInput.getDomain());
data.put("packageName", userInput.getPackage());
Writer out = new FileWriter(new File(outputPath));
template.process(data, out);

The Impact

The result is instantaneous. What used to take an entire afternoon of scaffolding is now reduced to a single terminal command.

Velocity: Microservice setup time drops from hours to <5 seconds.
Standardization: Every microservice generated across a team follows the exact same Clean Architecture folder structure. No more debating where the DTOs go.

Conclusion

Good developers write code. Great developers build tools so they have to write less code. ArchiGen was an exercise in prioritizing Developer Experience (DX) and proving that automation is always worth the upfront investment.

You can check out the CLI and the source code here: [https://github.com/mohamedmabrouk09/archigen]

From 0 to Production in 48 Hours: Architecting SmartPager

Mohamed Mabrouk — Fri, 08 May 2026 23:07:19 +0000

There’s a famous saying in engineering: "Fast, Cheap, or Reliable. Pick two." But when you enter a 48-hour hackathon to build a distributed incident management system, you are forced to pick all three.

This is the story of how my team and I built SmartPager from scratch, moving from a blank IDE to a production-grade alerting system in a single weekend.

The Problem with Incident Management

Incident management isn't just about sending an email when a server goes down. It's about concurrent event handling, real-time escalation, and ensuring that alerts trigger in sub-seconds. If the alerting system itself fails, it's useless. We needed a system that could handle failure scenarios gracefully.

Why Microservices?

The easiest route in a hackathon is a monolith. But we wanted to build something that mirrored real-world production environments. We chose a microservices architecture using Spring Boot, sitting behind an Nginx reverse proxy, backed by PostgreSQL, with a React frontend.

Incident Service : Ingests and processes incoming simulated incidents.
Notification Service: Handles the real-time routing and escalation of alerts.
Auth & Gateway: Handles security and load distribution.

Engineering Under Pressure: The Trade-offs

Senior engineering is about understanding trade-offs. With only 48 hours, we didn't have the luxury of spinning up an entire Kafka cluster for event streaming.

Instead, we engineered an event-driven escalation system using lightweight Spring Boot event listeners and optimized PostgreSQL indexing to process the state of incidents. We prioritized low-latency alerting over perfect eventual consistency, ensuring that when a simulated incident fired, the on-call engineer was notified in milliseconds.

The Outcome

When the judging phase arrived, we didn't just show them a PowerPoint. We bombarded the system with 100+ concurrent simulated incidents.

SmartPager didn't flinch. The distributed nodes handled the ingestion, the event-driven escalation triggered perfectly, and we achieved sub-second alert latency.

Conclusion

Building SmartPager taught me that system resilience isn't something you add at the end of a project; it's a feature you have to architect from minute one. You don't need infinite time to build distributed systems—you just need a solid architecture and the discipline to stick to it.

You can check out the source code for SmartPager here : [https://github.com/mohamedmabrouk09/incident-microservices]

DEV Community: Mohamed Mabrouk

Stop writing boilerplate: Building a Java CLI for Clean Architecture

Enter ArchiGen

Why Pure Java and PicoCLI?

How It Works Under the Hood

The Impact

Conclusion

From 0 to Production in 48 Hours: Architecting SmartPager

The Problem with Incident Management

Why Microservices?

Engineering Under Pressure: The Trade-offs

The Outcome

Conclusion