Interview with Kai Tödter (Siemens AG) on Micro Services, DDD, and REST
To kick off our Server Week, featuring workshops on architectures with
- Spring Boot,
- ASP.NET,
- NestJS and
- API Security
we spoke with Kai Tödter from Siemens AG about his experiences with Micro Services, DDD, and REST APIs.
Kai Tödter holds the position of Principal Key Expert for software architecture and technologies at Siemens Smart Infrastructure. With over twenty years of Java experience, he represented Siemens in the Java Community Process (JCP) and the Eclipse Foundation. Kai contributes as a committer to several open-source projects, and his current focus areas include web technologies, microservices, and hypermedia APIs.
Spoiler: Kai also serves as a trainer for Spring Boot as part of our Server Week.
Kai, you and your team at Siemens in Munich have been relying on DDD for quite some time. What are your key takeaways from all these years?
It's crucial that business and development speak about the domain using the same vocabulary, which is what we call the Ubiquitous Language. Moreover, collaborative workshops like Domain Storytelling and Event Storming are incredibly helpful for ensuring that everyone involved shares a consistent understanding of the domain. We've also observed that developers really value being able to use technology stacks like Spring, which offer support for both strategic and tactical design patterns.
How do you apply DDD in the frontend, and do you maintain the same domain boundaries there as in the backend?
It really depends on the situation. When we're building Self-Contained Systems, then yes, we do. However, there are times when we combine several bounded contexts within a single frontend application.
You've also been a long-time advocate for REST. How does resource-oriented REST align with DDD?
When you model RESTful services to implement a bounded context, it works well whenever a synchronous API over HTTP makes sense from the domain's perspective. This scenario is quite common in our environment, though we also frequently require asynchronous APIs or highly optimized implementations, in which case we don't opt for REST.
How do you go about implementing your services? What approaches have proven successful, and which ones haven't worked as well?
In my local context, Java implementations with Spring Boot and C# implementations based on .NET Core have proven effective, especially in cloud or container environments. For cloud or serverless scenarios, we tend to lean towards Go or TypeScript running on Node.js.
How do you consume your REST services, and how does your client handle the topic of hypermedia?
Our REST services are consumed by our frontends and, in some cases, by other services. Many of our services do support hypermedia; the links are then interpreted and processed by the frontends. However, we don't auto-generate anything. Instead, clients need to be familiar with the specific hypermedia format, such as HAL or JSON:API, and interpret the structure accordingly.
The Backend for Frontend pattern has become quite popular in the age of Micro Services. What's your take on it?
We employ BFFs whenever we need to aggregate data from multiple physical services for a single frontend. This approach often allows us to boost performance by reducing the number of remote calls from the frontend and by introducing other optimizations, like caching.
Services typically need to access other resources, especially databases. How do you handle this, and what lessons have you learned?
Our process often begins with analyzing the use cases within the domain to determine the type of persistence required. Frequently, a SQL database with appropriate O/R mapping is sufficient, but sometimes a NoSQL database is a better fit. We haven't encountered any performance issues with standard JPA so far.
Authentication is another topic that spans both frontend and backend. What's your approach here?
We consistently rely on standards like OpenID Connect and OAuth2. However, we've moved away from delegating authentication and authorization down to the frontend. In the past, we used to do that, for example, by initiating an Implicit Flow directly from the frontend. But this approach carries security risks, so we now use authorizing gateways. In this setup, frontends initially make unauthorized calls to the backend. A gateway sits in between and checks whether authorization already exists for the session. If not, the gateway initiates an Authorization Code Flow and caches the token, typically a JWT, using the session as the key.
Where do you see challenges in the collaboration between backend and frontend, or between developers who are more backend- or frontend-focused?
The biggest challenge, in my view, is that both frontends and backends are becoming increasingly complex, making it difficult for individuals to truly master both worlds. That's why I believe it's essential to have teams composed of both backend and frontend experts who can support each other and collaborate effectively. The key is for a team to work together towards the best possible overall solution, encompassing both the backend and the frontend.
A few more general questions
What advice would you give to your 20-year-younger self regarding software engineering?
Stay open to everything, constantly strive to learn and improve. Discuss your code with experienced friends and colleagues, and welcome any opportunity to make your code better.
What should be taught better or additionally in software engineering education, from your perspective?
There should be a greater emphasis on soft skills, communication, and collaboration.
In your opinion, what is working better in software engineering today compared to 10 or 20 years ago?
Agility has largely taken hold in software development and even in business. The whole DevOps movement has significantly narrowed the gap between Dev and Ops. DDD is now established and plays a significant role in helping business people and software developers understand each other better.
More on this: Server Week 🔥
You can dive deeper into topics like ✅ Micro Services, ✅ REST APIs, ✅ DDD, and ✅ modern Authentication in our Server Week, where we aim to "tell the rest of the story" about our backend architecture journey for frontends: