VenkatSubramaniam

In this workshop, take a practical approach to creating fitness functions that assess the architectural soundness of your systems.

In this workshop, take a practical approach to creating fitness functions that assess the architectural soundness of your systems.

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.

We have measures for health of a person, a process plant, an aircraft, etc. How do we measure the health of your applications, from the architecture point of view. Fitness functions are intended to provide a health status and can be useful to keep an eye on the system as the architecture evolves.

Design Patterns are common ways to solve problems that developers have discovered over time. They often fill the gaps between the language capabilities and the design goals. When languages mature, sometimes patterns become natural features of languages and blend in to the natural way of writing code instead of a special effort. Java has evolved significantly over the years.

Over the years we have learned and applied several software design principles. Many of these principles have been very useful and have served as guiding principles and, at times, as guard rails to develop better software. However, the principles do not work in isolation. They interplay with each other and sometimes even against each other.

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 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.

How does designing microservices differ from designing more traditional applications? What is a better way to learn than to take a problem, analyzing the requirements, exploring the design options, applying the concepts of bounded context, and arrive at the architecture and design of Microservices to realize the requirements?

Why talk about resilience when thinking of scale? It turns out all the effort we put in to achieve great performance may be lost if we are not careful with failures. Failure is not only about unavailability of parts of an application to some users, it may result in overall poor performance for everyone else as well.

Most mainstream languages started out with support for multithreading. Threads were considered lightweight but that term is relative. Threads were not ideal from the point of view of resource utilization and they often lead to higher cost of deployment. There has been a greater emphasis on asynchronous programming in recent times, due to the nature of applications and the architectural patterns they tend to favor.

There are many architectural patterns, from monoliths to distributed architectures. It can be daunting to choose between them.

There are many architectural patterns, from monoliths to distributed architectures. It can be daunting to choose between them.

Creating good design take effort and is an incremental process. Red-green-refactor is the mantra of TDD. As we continue to evolve the design, how do we know if the design needs some tweaking, or a lot, or is in a pretty good shape... from the extensibility and maintainability point of view. This is where measuring the quality of design comes in.