Paulo Merson

Paulo Merson

Getting wiser but remaining silly
· Twitter · LinkedIn ·
· IDEALS for Microservice Design


Paulo Merson has been programming in the small and programming in the large for over 30 years. He is a software developer at the Brazilian Federal Court of Accounts. He is also a Visiting Scientist with the Software Engineering Institute (SEI), a certified instructor for Arcitura, and a faculty member of the master program in Applied Computing at University of Brasilia. Paulo often delivers professional training to fellow developers in the United States, Latin America, and Europe. His speaking experience also includes tutorials at JavaOne, SPLASH/OOPSLA, SD Best Practices, SATURN, Dr. Dobb’s Architecture & Design World, The SOA and Cloud Symposium, lectures to graduate students in different universities, and invited talks at different companies. He is co-author of Documenting Software Architectures: Views and Beyond, 2nd edition. Paulo holds a Bachelor of Science in Computer Science from University of Brasilia and a Master of Software Engineering from Carnegie Mellon University.

IDEALS for Microservice Design (Lab)
by Paulo Merson, Joseph Yoder

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, there's 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 discuss how these IDEALS can be realized using different patterns, techniques, and tools to create microservice architectures.

In the practice part of the session, you will create a design solution to a given problem, choosing patterns we discussed, and pondering about the tradeoffs.

Join the mailing list

for updates about the DDD Europe Conference and workshops