VenkatSubramaniam

The modern systems we build, whether they are distributed monoliths, service-oriented systems, or microservices, involve multiple moving parts that continuously change and evolve. One of the nightmares for every developer is waking up to calls that their service does not work because another service they depend on downstream has changed. A sensible solution would be to know of changes well ahead of time to prevent applications from breaking or falling apart. Consumer-Driven Contracts, which serve as executable documentation of the interface between systems, are a good proactive way to ensure that.

Architecture is not a static representation of a system. There are several complexities and risks involved in creating them. One way to mitigate the risk is to evolve the architecture. But, there are risks of evolving as much as there are the risks of not evolving. In this interactive workshop we will explore a set of practices that we can use to mitigate the risks. Then we will dive into discussing some common and popular architectural patterns.

Design patterns are commonplace in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.

Functional programming has been around for a long time, but in recent years almost all mainstream languages have eagerly embraced it. Developers are no longer thinking it is a good idea, but are building systems with the constructs of functional programming. In reality, we are building systems with hybrid models, imperative, object-oriented, and functional paradigms.

Many developers around the world have jumped on the Microservices bandwagon. Several organizations, in the past and also in the present, have built around monolithic and also service oriented architectures. What separate, however, Microservices from those efforts at large? How does a Microservices based architecture influence the design of the software applications, what are the key design principles we should keep in mind, and how to leverage design goals like reuse and extensibility?

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one?

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

We all are familiar with SOLID and other software design principles and have explored many design patterns. There is no better way to get a deeper understanding than to practice the concepts. Furthermore, some of the principles and patterns manifest themselves in what appear to be rather unconventional ways when applied under a set of constraints and requirements.

We all are familiar with SOLID and other software design principles and have explored many design patterns. There is no better way to get a deeper understanding than to practice the concepts. Furthermore, some of the principles and patterns manifest themselves in what appear to be rather unconventional ways when applied under a set of constraints and requirements.

The vast majority of developers have experience creating monoliths. Whereas that experience is really good to have from the point of view of building monoliths, they may become a hindrance when creating microservices. There are a few things we have to do differently, we have to unlearn a few design principles, we have to adhere to a few different architectural goals, and yet carry forward some of the techniques that have worked well before.