On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.
Track: Back to Architecture
- Back to Architecture
- Business Agility
- Design Erosion & Learning from Failure
- DevOps & Continuous Everything
- Diversity & Inclusion
- Domain-Driven Design moving forward
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern C++ Programming
- Modern Enterprise Architecture
- Product Discovery, Customer Centricity & RE
- Signature Track: Back to the Future
- Social Integration
- Special Event
- Testing & Quality
- Trends & Techniques
SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":
(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.
(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.
(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call.
(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency.
(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Modern architectures (e.g. event-driven and reactive) will gain more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, many companies don’t update their business processes to reflect this. I’ll give an example and discuss the consequences, motivating you to advocate for a redesign of your business processes internally. Too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.
Target Audience: Architects, Developers, Business Analysts
Prerequisites: Experiences with software architecture
There is a lot of buzz around reactive architectures. Take, for example, event-driven architectures, event-streaming or reactive programming. These architectures will gain more and more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, I see many companies that don’t update their business processes to reflect this new world. In this talk, I’ll give an example and discuss the consequences, hopefully motivating you to advocate for a redesign of your business processes internally–because too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.