Resources

 Strategic Domain Driven Design Tools for Non-DDD People

DDD has a reputation for being esoteric and hard to grasp for newcomers. So the community has been working hard to simplify the user experience for people new to DDD by providing practical tools like the Bounded Context Canvas which even people with no prior DDD experience can benefit from to design loosely-coupled microservices. These tools will provide you with instant value. You can use them right away on the systems you are building. The tools also help you on the path to mastery of DDD. And all of the tools are open source and creative commons, so nobody is trying to sell you anything.

DDD Video

 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

 Clean Architectures in Python

Architectural considerations are often overlooked by developers or completely delegated to a framework. We should start once again discussing how applications are structured, how components are connected and how to lower coupling between different parts of a system, to avoid creating software that cannot easily be maintained or changed. The ""clean architecture"" model predates Robert Martin, who recently brought it back to the attention of the community, and is a way of structuring applications that leverages layers separation and internal APIs to achieve a very tidy, fully-tested, and loosely coupled system. The talk introduces the main ideas of the architecture, showing how the layers can be implemented in Python, following the content of the book ""Clean Architectures in Python"" edited by Leanpub. The book recently reached 25,000 downloads and many readers found it useful to start learning how to test software and how to structure an application without relying entirely on the framework.

Architecture DDD Python 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

 Real World Micro Services

Over the years I’ve become pretty frustrated by the state of tech and engineering in general. One of the biggest issues we face in the industry is the lack of reusability in software. GitHub made a major revolutionary change for developers, enabling all of us to reuse libraries, and code through reuse rather than writing everything from scratch. Yet it never felt like that made it any further than that.

Go Microservices

 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

 Event-Driven Architectures Done Right

Far from a controversial choice, Kafka is now a technology developers and architects are adopting with enthusiasm. And it’s often not just a good choice, but a technology enabling meaningful improvements in complex, evolvable systems that need to respond to the world in real time. But surely it's possible to do wrong! In this talk, we'll look at common mistakes in event-driven systems built on top of Kafka: -Deploying Kafka when an event-driven architecture is not the best choice. -Ignoring schema management. Events are the APIs of event-driven systems! -Writing bespoke consumers when stream processing is a better fit. -Using stream processing when you really need a database. -Trivializing the task of elastic scaling in all parts of the system. It's highly likely for medium- and large-scale systems that an event-first perspective is the most helpful one to take, but it's early days, and it's still possible to get this wrong. Come to this talk for a survey of mistakes not to make. Lecture took place on Wednesday 25th August 2021 at 13:30 in Room 1 Tim Berglund is a teacher, author, and technology leader with Confluent, where he serves as the Senior Director of Developer Advocacy. He can frequently be found at speaking at conferences in the United States and all over the world. He is the co-presenter of various training videos on topics ranging from Git to Distributed Systems to Apache Kafka. He tweets as @tlberglund, blogs very occasionally at http://timberglund.com, and lives in Littleton, CO, USA with his wife, their three children having grown up. Topics covered: -What is Event-Driven Architecture -Data Mesh Principles -Scaling -State management

Architecture Best Practices Event Sourcing 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