Hello world! I’m Robert Zilke, a Software Engineer from northern Germany, driven to make the world a better place with the power of automation! I specialize in backend development, with a strong focus on building maintainable, robust, scalable, and efficient systems. My expertise includes designing sustainable software architectures using frameworks like Spring Boot, writing clean and maintainable code, and developing automated tests to ensure the reliable delivery of domain-specific solutions. I'm proficient in database management and optimization, ensuring data integrity and efficient access patterns. Additionally, I have extensive experience in creating RESTful APIs, leveraging modern technologies like Docker and Kubernetes for containerization and orchestration. My attention to detail and commitment for clean code allow me to craft backends that are both powerful and reliable, ready to scale with evolving business needs.

Exploring new tools and techniques isn't just work for me — it's a passion. I believe that the more tools you master, the better equipped you are to choose the ideal one for any challenge. Java is my primary programming language, though I have also worked extensively with Groovy, Dart, JavaScript, and more. I possess in-depth knowledge of the Spring ecosystem, including Spring Data and Spring Cloud. In today's development landscape, I consider Docker an essential tool, particularly for efficient local development.

In addition to my development expertise, I have substantial experience on the operational side, ranging from privately hosting various services using Docker-Compose to managing enterprise-scale infrastructure with Kubernetes and custom provisioning technologies. For more details, be sure to check out my Projects.

My thoughts and experiences with...

Microservices

The greatest advantage of microservices is that they enforce modularization, encouraging a more structured and encapsulated codebase. In theory, they seem like the perfect approach for building modern software. I was initially caught up in the microservices hype as well. In fact, I dedicated my master’s thesis on examining the benefits and challenges of microservices, particularly in the context of service discovery. However, in practice, they come with significant operational overhead.

After years of developing and maintaining multiple microservices, my teams and I often found ourselves merging services together. This approach allowed us to maintain strong modularization while ensuring the system remained extendable and maintainable.

Microservices are particularly beneficial in two scenarios:

1. When the operational advantages outweigh the complexity they introduce. For instance, if you need to scale a specific component independently without scaling the entire application.

2. When there are changes in organizational structure, such as splitting a team into smaller units, where each team needs to work autonomously on separate applications without constant communication. However, even in these cases, a well-modularized architecture within a single application can often achieve similar benefits.

In both scenarios, having a well-thought-out modular architecture makes any transition much smoother.

I once had the fortunate opportunity to meet Sem Newman, the author of Building Microservices. During our conversation, he gave me a valuable advice:

Don’t build microservices unless you have a really good reason.

Modularisation is the key!

Domain Driven Design

Clear communication within a software project team, including developers and domain experts, is a critical factor for success. Domain-Driven Design (DDD) provides an excellent framework to streamline this process by fostering a shared language that bridges conversations in meetings and code.

DDD shines not just at the architectural level but also in the smallest details of a software project. For instance, consider Java classes: embedding domain-specific functionality directly within domain classes, instead of relegating it to separate utility classes, makes code more maintainable. It also gives domain experts the ability to understand what the code does, without requiring programming expertise.

At the structural level, organizing packages and modules based on domain purposes rather than technical functions keeps related code closer together. I vividly remember my former colleague Arne Limburg, who taught me a lot about DDD, asking:

Why should two classes share a package if they are completely unrelated?

Such insights emphasize the value of aligning structure with domain intent.

For larger projects or complex domains, conducting Event Storming and defining Bounded Contexts are key DDD practices that can deliver immense value. While it involves initial effort and ongoing maintenance, the payoff is a more robust and manageable development process.

My Advice: Take the low-hanging fruits. Apply simple DDD patterns that are easy to integrate, such as clear naming conventions and organizing code by domain. For more complex domains, it’s worth investing the time to define Bounded Contexts to ensure long-term reliability and maintainability.

Arc42

Arc42 is an excellent template for software architecture documentation. It offers a unified structure with well-designed chapters that help clarify the project’s objectives, neighbour systems, its building blocks across different abstraction levels and the architectural decisions made.

Arc42 can also be used for existing projects. Thanks to its standardized structure, it helps stakeholders of all types quickly find the information they need. By referencing existing documentation, Arc42 enhances its strengths without requiring a complete restructuring of your current materials.

For my iSAQB certification, I was fortunate to meet the inventors of Arc42, Gernot Starke and Peter Hruschka. They shared a key principle:

Arc42 should be used like a cabinet for architectural documentation. If something isn’t there, then it doesn’t exist.

While transparency in architecture is essential, being economical with documentation is just as important since it needs to be maintained. Peter and Gernot emphasized this point:

Incorrect documentation is worse than no documentation.

Having an Arc42-based documentation is a tremendous advantage for onboarding new team members and fostering team discussions about adding new features, redesigning the structure, or tackling other activities.

I use Arc42 in all my projects, regardless of size. Arc42 scales effortlessly and doesn’t require you to fill every chapter with content. It simply provides a space for important information when needed.

Personally, I think that drawing diagrams with arrows is a simple yet powerful way to convey complex ideas. As a result, all my Projects include a context view to enhance understanding.