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.\n\nUsing technical visuals and a careful planning process, you can outline your software architecture and design before you get started on a prototype.
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.
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.\n\nThis 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.
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.
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.\n\nUnfortunately, 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.\n\nHowever, many companies, including Snap, Uber, and Netflix, are adopting a new paradigm: Workflows. Workflows are to distributed systems what transactions are to databases.\n\nThis 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!
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.\n\nYou can decrease the time you waste reading complicated code by writing code that's easy to read - code that fits in your head.\nCode 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.\nKey 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.
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?
If you’re a software developer or architect who wants to play a more influential role in ensuring your software systems are optimised to support business goals, then you need to learn about the benefits and techniques of modern strategic domain-driven design.\n\nMany people think that DDD is about software design patterns, but that’s only a small part, and the least important part of DDD. In fact, Eric Evans wishes he’d focused more on the strategic aspects of DDD in his famous book (Domain-Driven Design: Tackling Complexity in the Heart of Software) and pushed the tactical coding patterns to the back!\n\nStrategic domain-driven design is about truly understanding the business domain. It involves collaboratively modelling business processes using advanced modelling techniques, like Event Storming and Domain Storytelling, with domain experts on an ongoing basis.\n\nOne of the core outcomes of strategic DDD is identifying cohesive modules, known as bounded context. Bounded contexts help you to create a maintainable, comprehensible codebase by isolating dependencies and delineating concepts that reference different classes of business value.\n\nIn this talk, you’ll see many of the most effective bounded context design heuristics, recurring patterns in the wild, and you’ll learn how to facilitate those vital modelling sessions so you can lead the adoption of strategic DDD in your organisation.
Software architecture should enable business agility, but often it does not happen because of the mismatch between product design and software architecture. In this talk, Sandro will describe how a software design approach, focused on behavior and also driven by external interactions and business flows, can enable better collaboration between business and technology. This talk shows techniques (used in real projects) to bring product and software design together, at the same time, produce an Agile architecture that is more resilient, focused, and fully aligned to business goals.