Transactions in a Microservice World

Typically, microservice-based applications distribute data widely, especially in cloud-based applications, resulting in distributed applications. This impacts the transactions within these applications. This white paper refreshes the concepts of classical and distributed transactions. Next, we explain how cloud-based applications are affected by distribution. Finally, we present compensation-based transactions as a reliable method for microservice-based application transactions, even in the cloud.

Design Microservices

 How do committees invent?

When I think about design, I more naturally think about it the other way around: how to decompose the whole into a set of parts that will work together to accomplish the system goals. But of course Conway is right that those parts do have to fit together to produce the intended whole again.

Design Philosophy

 How to design software architecture: Top tips and best practices

You wouldn’t want to jump into a project without a solid plan, and software architecture design is no different. By making this process more effective, you can account for all of your requirements properly and give stakeholders the opportunity to provide their input. Using technical visuals and a careful planning process, you can outline your software architecture and design before you get started on a prototype.

Architecture Design

 Why Understanding the Problem Domain Matters in Software Development

As software developers, we might think that our main job is to write code and create solutions. But really, our most important job is to understand the problems we're trying to solve. In this article, we'll talk about why it's important to understand the problem domain, why this helps us build better software, and how developers can get better at it.

Design Philosophy Software Development

 Aligning Bounded Contexts with Subdomains in Legacy Code

One way or another, each system contains some kind of boundaries. I would go so far and claim that even the dreaded Big Ball of Mud systems consist of parts that could be perceived as separate though undoubtedly only under deep scrutiny. The difference is in the “thickness” of the boundaries and the measure of interrelationships between the different parts of the system, the frequency and amount of data that is passed across the fences. It is the latter that leads to increased coupling resulting in systems that are hard to maintain and hard to change. This presentation will present a story of an attempt to achieve an alignment between perceived subdomains, logical boundaries and source code structure in a legacy system. Based on the use case from healthcare we will go into technical detail on concrete steps that were followed to create a new bounded context using strategic Domain-Driven Design and 4+1 Architectural View Models.

Architecture DDD Design Video

 Balancing Coupling in Software Design

We are used to treating coupling as the necessary evil. Hence, we aim to break systems apart into the smallest services possible, in the ever-lasting quest of decoupling everything. But what results are we getting by following this reasoning? — Instead of the promised land of evolvable systems, many such “decouple everything” endeavors lead straight into the chains of distributed monoliths. Can we do better? What if there is a better way to handle coupling in distributed systems? Or even, what if instead of fighting coupling, we can use it as a heuristic for designing systems that are actually evolvable and maintainable? That’s exactly what you will learn in this session: what coupling is, and how you can use it as a design tool. We will start by taking a journey through time, and explore the different models of evaluating coupling. Next, we will combine the existing knowledge into a coherent model — a simple function for evaluating a system’s decomposition into components. This function will allow you to assess the expected effort for evolving a system and use it as a heuristic for optimizing architectural design decisions.

DDD Design Video

 Workflows, a new abstraction for distributed systems

For the past 45 years, the database systems community has enjoyed an unparalleled developer experience: Database Transactions mitigate challenges such as failure on a platform level, entirely eliminating these challenges on an applications level. Unfortunately, the distributed systems community has not enjoyed a similar developer experience: There was no equivalent abstraction that mitigates challenges like failure on a platform level. However, many companies, including Snap, Uber, and Netflix, are adopting a new paradigm: Workflows. Workflows are to distributed systems what transactions are to databases. This talk explores how Workflow Systems mitigate challenges on a platform level and provide a developer experience for distributed systems that rivals the developer experience for databases, allowing you to literally code as if failure does not even exist!

Abstraction Architecture Design Video

 Fractal Architecture

Why is software development so difficult? A major reason is that you spend more time reading than writing code. If you can decrease the time required to read existing code, you can increase productivity. You can decrease the time you waste reading complicated code by writing code that's easy to read - code that fits in your head. Code should fit in your head at all levels of abstraction. At the entry point, at the business logic level, and at the lowest levels of detail. This is fractal architecture - code that is organised according to that principle of self-similarity. Key to achieve fractal architecture are encapsulation, aggressive thresholds, and referential transparency. Code examples will be in C# - written in a style also readable to developers working in Java, TypeScript, C++, etc.

Design Video

 CUPID—for joyful coding

What started as lighthearted iconoclasm, poking at the bear of SOLID, has developed into something more concrete and tangible. If I do not think the SOLID principles are useful these days, then what would I replace them with? Can any set of principles hold for all software? What do we even mean by principles?

Design SOLID

 Introduction to Domain Modeling

DDD Design Video