SATURN 2019

The Don’t Repeat Yourself Principle has swept the world. It is often the first thing new engineers are taught. It has probably affected your current code base in a big way. However, despite your code being "DRY," your code is hard to change. Files have to be changed for seemingly unrelated reasons as shotgun surgery and code brittleness abound. You might ask yourself, “Why is this happening?”

In this talk, I will show you that the DRY Principle actually is about eliminating duplicate representations of “concepts” in their system. Duplicate code is often misidentified as part of this principle, and attempts to clean it up are made. The end result is lots of shotgun surgery (many places change for the same reason) or divergent change (one place changes for many). This yields tons of pain for the development team, and eventually a clamor for a complete rewrite of the system.

I will give you three techniques to highlight incorrectly DRY code. These are

• focused conversations with the product team
• asking yourself the question "can I reason about this separately?" before you remove duplication
• how to notice shotgun surgery or divergent change

Once you know how to identify incorrectly DRY code, I will walk you through a code example where introducing a new path is very difficult. We will refactor the code so that the independent concepts are isolated. Once the code is fixed, I will show how easy it is to make the desired change—no extra conditions required.

See the slides.

Watch the video.

Many have suggested using domain-driven design (DDD) to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. DDD is a domain modeling technique created in the early 2000s. Microservices is an architecture style that became popular in 2015 as means to break software solutions into a set of independently deployed services. In this talk we'll cover basic DDD concepts, and we'll discuss why and how DDD can help create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.

See the slides.

Watch the video.

This talk presents a few of the major Java-based reactive frameworks and toolkits in the market today, such as RxJava, Spring Reactor, Akka, and Vert.x. It will start by going over the basic tenets of reactive systems and some examples of the problems that these systems aim to solve. It will discuss the two most commonly used Java frameworks for implementing reactive coding, RxJava and Spring Reactor, and will show some code samples. It will then bring the audience to the next level of “reactivity” by introducing two reactive frameworks, Akka and Vert.x, which are usually used for implementing reactive microservices. It will draw some comparisons between these two frameworks and cite some real-life examples of their usages.

The takeaways for the audience will be an understanding of the key differences between reactive programming versus reactive systems, and the strength and weaknesses of each of the surveyed frameworks.

See the slides.

Watch the video.

Machine learning (ML) is everywhere, and there is a lot of material that discusses many of the difficulties associated with creating an ML solution from a data science point of view. This work covers aspects related to obtaining data, selecting a particular algorithm, and training and testing the algorithms. There is, however, less information related to architecting the software system where this algorithm will be running once it is in production. In this talk, we want to address this topic, both from a theoretical and practical point of view. Our goal is to help software architects that need to design systems that support ML by identifying common architecture design considerations for various phases of data processing, training, and model serving.

We will cover the following topics:

1. Where does software architecture fit in systems that support ML?

2. A framework for gathering primary architectural decisions of systems that support ML. These decisions include aspects such as
* type of training of the model and model location
* time of training: offline vs. online
* time of prediction: batch vs. on demand
* location of prediction: cloud vs. device
* technological choices
* other considerations

3. Several case studies of systems developed at SoftServe that support ML using the previously discussed framework.

4. Synthesis: What needs to be considered when architecting ML systems?
* Lessons learned
* Design process considerations

See the slides.

Watch the video.