What we seem to be missing is a deep sense of how the way that we work and the way that we organize ourselves resonate with our systems’ structure, lifetime and maintainability.

In this keynote, Michael Feathers will outline a process view of system structure along with a description of various forces that can be present in systems design. He will also show that seeing these can help us anticipate problems and create simpler systems.

Andrew and Gayathri's talk tells the story of a large-scale DDD implementation that got complicated. They'll talk about how took stock of the situation as they found it, how they identified where the root problems lay, how they set everyone off on a course of success, and the mistakes they made along the way.

Regardless of whether you are working with microservices or a more monolithic architecture (nothing wrong there!) - this talk is for those who want to learn the lessons of implementing DDD at scale, with a healthy dose of pitfalls and hazards to watch out for too.

A startup cannot afford to waste time, so why did they choose to build with microservices first when they take more effort and infrastructure to deploy?

This would surely have slowed them down! And what about working with multiple remote contractors on short term contracts—don't they all have to be on-boarded? This is madness! They learned a lot, and made a lot mistakes, but they would definitely recommend using microservices from day one for startup—find out why!

In this talk, you’ll discuss how you can move from your current stack to a Cloud Native stack. you’ll cover the buzzwords you might have heard of (Kubernetes, Prometheus, Istio, Serverless for example) and some that you might not. By the end of this talk you will have a good enough understanding of Cloud Native technologies and be able to start planning your route to it.

This talk is suited for anyone who has to deal with the running applications on a day-to-day basis as well as the decision makers and product owners.

In this presentation, Jimmy will discuss what really matters. Domain-Driven Design is very important to him, so it should come as no surprise that he believes deep collaboration with the domain experts to be one of the most important things to do and master. He'll delve into this in ways you probably haven't tried yet. Furthermore, he will discuss five other musts for reaching excellency.

The developer experience with modern cloud-native technologies is very different than the classic enterprise experience of the 1990s or even the early cloud experiences of the 2000s. For example, it’s often no longer possible to spin up an entire application or system on local hardware, and the extra layers of abstract of containers and VMs make debugging and observing systems more challenging.

Daniel Bryant explores the core concepts of the cloud-native developer experience, introduces and compares several useful tools, and shares lessons learned from the trenches.

But replicating search functionality for your own uses or users isn’t that simple, especially with microservices. Trying to retrieve data from multiple tables - never mind different databases or clusters – can easily balloon in complexity and load on your system.

That’s why Landbay built their own search microservice. Using Elasticsearch, custom indices, and event-driven messaging design patterns, a separate search microservice provides fast and flexible access to data across the whole platform. Searches happen in near-realtime, the frontend is able to dynamically generate search tables, control is centralized in configurations to make creating new searches a breeze, and you can completely re-index the system without any disruption to users.

Of course, the end result isn’t exactly the same as Google, but it definitely beats using complex search query boiler plate. Or Bing.

We’re all developers, but we’re not doing the same job. The line connecting a problem to its solution is relatively straight in some organizations and incredibly convoluted in some hours. Processes, Software architectures and Organization are not separate concerns, neither are orthogonal. Pretending to fix one thing without touching others is a losing battle. We’re part of the problem. Our software is part of the problem. We can be part of the solution too.

As an R&D director at Taboola, Ora had the opportunity of leading a technical due-diligence of an acquired company. During that time Taboola considered a few alternatives of how such an acquisition might look like from two main perspectives: organization structure and technical integration whereas the two obviously affect each other per Conway’s Law.

In addition, post acquisition previous assumptions turned out to be inaccurate and required further domain analysis, for finding a better solution.

During those challenging times, Ora found DDD to be a very practical tool for executing the relevant change.

If you are in a dynamic company where teams, products and domains grow fast and then split or merge, you need to constantly analyze the domains and consider alternatives for those changes. From his experience, DDD approach helps visualizing and considering these alternatives while being able to keep the discussion both business and technical.

In this talk, Ora will share the two years journey post acquisition. A journey in which domains merged and split due to a dynamic environment, for example: -Why they used DDD to decide an acquired team should stay as an isolated domain, acting as a supportive domain in the company -How they later merged part of a supportive domain into the core domain -How and why they ended up splitting the merged domain again

By aligning your microservices with your business domain, you create a software system which is easier to comprehend, easier to evolve, and easier to develop at speed because it can change with the business. Understanding domain patterns helps you align your microservices and your business domain. Learn why it’s important not to confuse The Entity Lifecycle Pipeline and The Proposal Pipeline. Learn how to manage complexity, and politics, when your domain contains an Octopus Context. And learn about many other domain patterns including The Dogfood Context, The Engagement Context, and The Brain Context. To create the best architecture you also need to understand the business model. By viewing your microservices as business capabilities aligned to domain patterns, you will be able to design the best architecture for your business and for the teams building your microservices.

In this talk you’ll learn 18 different heuristics to help identify the boundaries of your Bounded Contexts and services, and to gain confidence before committing to your decision. You’ll discover how to split your monolith correctly. And it will be fun, with a few other surprises as well!

The question is – how do you build your systems in a way that security incidents won't happen even if some components fail. And the data leaks won't occur even if penetration tests are successful.

"Defense in depth" is a security engineering pattern, that suggests building an independent set of security controls aimed at mitigating more risks even if the attacker crosses the outer perimeter. During the talk, Anastasiia will model threats and risks for the modern web application, and improve it by building multiple lines of defence. She will overview high-level patterns and exact tools from the security engineering world and explain them to the modern web devs ;)

She won't: crack real applications, discuss how insecure JWT tokens are, steal WiFi passwords

She will: discuss practical security engineering approaches, cover security controls from complex encryption schemes to modern DevOps tools

What happens if Ian needs one service needs to talk to another about a shared concept such as a product, a hotel room, or an order? Does every service need to have a list of all our users?

Who knows what users have permissions to the entities within the microservice? What happens if his REST endpoint needs to include data from a graph that includes other services to make it responsive? And he is not breaking the boundary of his service when all of this data leaves his service boundary in response to a request?

Naive request-based solutions result in chatty calls as each service engages with multiple other services to fulfill a request, or in large message payloads as services add all the data required to process a message to each message. Neither scale well.

In 2005, Pat Helland wrote a paper ‘Data on the Inside vs. Data on the Outside’ which answers the question by distinguishing between data a service owns and reference data that it can use. Martin Fowler named the resulting architectural style; Event Driven Collaboration. This style is significant because it shifts the pattern from request to receiver-driven flow control.

In this presentation, Ian will explain how events help us integrate our service architectures.

In the first part of his talk, Martin will show that events form the basis for a simple yet robust model that makes the technical complexity of distributed systems manageable. What distinguishes service internal events and event sourcing from service-external integration events? What connects both topics? Which DDD ideas and concepts help to get closer to the promise of low service coupling through events?

In the second part, Martin discusses why events and pub/sub seem to help less in business-wise complex scenarios. Does a practical need to model promises, intentions and contracts between services directly force us back into old school orchestration? Not necessarily! Martin will suggest and explore a powerful "choreography 2.0" pattern, with which the moment an intention emerges is modeled as a historical fact.

Last not least: expect Martin to show real code modeling event sourced sagas - plus a type safe (Kotlin) DSL to describe sagas declaratively.

But after the dust settles and we all realize that we don’t know when the next critical failure is, how do we start gaining visibility on the health and fitness of our systems? Are dashboards the answer?

JB talks about his journey from how he and his team evolved visibility in their systems, reduced those 3am calls, proposes throwing those overhead dashboards in the bin and looks to the future of how we could build self-monitoring software.

This talk will provide practical steps on how to simply do this. It’ll provide you with the pillars which form the foundational platform for helping you better understand how your systems are performing.

When you talk about creating an application from scratch, you often cannot imagine the evolution of its ecosystem without building more and more services, one by one.

In this talk, Liz will discuss why your security team might have concerns about a microservices-based architecture, and then you'll see how, by adopting DevSecOps and automated processes, and some of the tools and capabilities of a cloud native architecture, you can strengthen your security defences. There will be demos!

Domain modeling in particular is very specific with guidance on designing and coordinating the dance between the myriad moving parts in our system. Yet learning the principals of DDD can be daunting for developers who are new to DDD.

To encourage and enable more developers to get on the path of DDD, is it reasonable to allow a more pragmatic approach over a principled approach of adhering strictly to DDD guidelines?

Should developers be encouraged to start with low hanging fruit which they can quickly benefit from in their software projects while they continue to learn, to gain a deeper understanding of Domain-Driven Design in order to evolve and adapt their practices as they move closer and closer to the beauty we all know that can be achieved with DDD.

Join Tugberk in this session where he will walk you though an evolvable software architecture based on Domain-driven Design and CQRS, which can let you optimise for today's problems at the same time allowing you to design towards event sourcing. You will also start understanding the concepts of Hexagonal Architecture pattern, which puts the Domain at the heart of the system and pushes the input and output at the edges.

This talk will give you some techniques to let you be tactical about your architectural approach, which will be especially handy when conflicts arises between business needs and refactoring costs.

The short answer to that could be to build your core domain - that differentiates you from your competitors - in-house and outsource undifferentiating commodities to utility suppliers.

In this talk Susanne will use Wardley Maps to visualise how the value chain can evolve when getting infrastructure components handled by different options: Going from open source software to Kubernetes' container orchestration, to Istio's service mesh and to Serverless technologies, such as AWS Lambda.

A traditional approach is to reproduce the domain as accurate in every detail as possible – building the company-wide canonical domain model. But is this the actual goal of models? If you look close enough, you will see that a model is the exact oposite—a model is actually an abstraction of the reality in which only the essential parts are transferred. The inessential is left out of the model. What parts of the reality are essential or inessential is defined by the context.

A simple model is easier to understand than a complicated one. Therefore, it is a good idea to break a complex reality (i.e. domain) into multiple simple models. Exactly this effect is what the strategic design of DDD takes advantage of. Here instead of one complex company-wide model we build several small models that are easy to understand.

In this talk Henning will look into bounded context and the other tools that are available to to divide the domain into clearly separated models.

Maria Gomez explores the most important operational concerns for maintaining microservices and explains why observability helps you in maintaining a healthy production environment.

Metamodels provide a solution to the horizontal layering problem. In the same way that an ORM such as Hibernate uses a metamodel to separate the domain model from its persistence model, so too can a metamodel be used to - among other things - separate out the application and presentation layers.

Splitting vertical subdomains is a different challenge again, but DCI - an evolution of the well-known MVC pattern - is an architectural style that helps achieve that goal. Distinguishing between data (what the system is), interaction (what the system does), and context (what the user is trying to do), it sits somewhere between aspect-oriented and object-oriented approaches. Its the aspect-oriented nature that allows functionality to be partitioned into vertical submodules but nevertheless be presented in a coherent fashion to the end-user.

So much for the theory. In this live coding session we'll look at a framework that marries both of these techniques, resulting in applications with clean separation both vertically and horizontally.

That was the case a few years ago at Fiverr, the world's largest marketplace for digital services. After adopting a Microservices architecture, development was a breeze compared to the mighty monolith... but once the honeymoon period was over thier progress was slowing down as they encountered issues such as:

• Losing transactionality inside a service boundar
• Unclear data ownership
• Intertwined and non business focused services
• Dependency graph for deployments

If you feel you are approaching the end of your Microservices honeymoon period, then this talk is for you!

Erik will explain what DDD's Strategic Patterns are and how adopting them helped them to better align their tech with the business, facilitate team autonomy and ownership and most importantly deliver high quality products faster!

The approach of micro frontends is an effective strategy to tackle this problem and first appeared at the end of 2016 on the ThoughtWorks Technology Radar. By going into detail about the idea of extending the concepts of microservices to the frontend world, the importance of end-to-end verticals, the difference of an orchestration- or choreography-based implementation, and the trade-offs in reusability become reasonable.

Upon a closer look at the advantages and challenges you’ve experienced in customer projects, it turns out that micro frontends are not a silver bullet either. Rather, they are suited for a specific set of problems. In a nutshell, micro frontends can be a powerful tool to avoid frontend monoliths and this talk will give you the needed knowledge to decide if it’s the right one for the job.

Automating examples brings huge benefits, but standardised BDD practices can feel artificial. We'll see a typical Gherkin-oriented methodology and how it works, then explore some more natural visual formats for examples, and how they can practically be used to drive tests.

You’ll deploy application to a pod, expose it with a service and manage it on an ingress. You’ll then look at deployments, and scale our application. Finally, You’ll try and break our application.

This workshop is for anyone who hasn’t used Kubernetes before and wants to get started. There are no prerequisites, all the work will be done via a browser on a remote machine. To participate in the workshop you’ll require a laptop or tablet.

Thomas and Bruno will propose you join them to experience a workshop where you will practice Event Storming reinforced by Example Mapping.

Through a sample Java code base, group interactions and fun, you will have a first grasp on Living Documentation, at a fast pace!

Audience Learnings:

Get a grasp on the Living Documentation principles and the main traps to avoid, and learn concrete solutions to implement Living Documentation in code.

Prerequisites:

• Setup from github or a USB key
• A working Java IDE with Maven, WiFi

Systems architecture is the art and science of conceptual decision making. What is the best possible solution under the circumstances? The circumstances are always uncertain. And the people considering them usually have disparate views of “best” and “possible”.

Yet, people must make interdependent and interrelated decisions if the goal is conceptual integrity. Fred Brooks says that conceptual integrity is “the most important consideration in system design.” The value is clear: the quality of your conceptual thinking becomes the quality of the system itself.

The antithesis to integrity, Brooks says, is a system with “many good but independent and uncoordinated ideas". Isn't that how many projects approach product development? Products that might seem, conceptually, independent are, more and more often, a coordinated part of an emergent system.

The success of those systems depends on building bridges between business and technical, strategy and implementation, product engineering teams and other product engineering teams. To do this, you stretch your thinking beyond specific technology solutions, into the world in which the problems exist. And you become very, very good at making a strong collaborative case for how to solve those problems.

The talk will use a mix of examples from Government to the Private sector, from infrastructure to serverless and try to answer the question of whether there is a right choice or is every journey different?

By separating behaviour and state, lean models offer an effective and scalable way to represent units of behaviour. With the advances in cloud-based infrastructures and implementation of microservices architectures, functional models seem to be a compatible, resilience enabling and more obvious choice as the preferred paradigm.

Have any anti-patterns crept in, do I have the dreaded distributed monolith?

This talk explores how network science techniques can be applied to help gain insight into, and explore questions about your microservices architecture.

Let’s take a deep dive into how Yan and his team did it, and improved performance, scalability, and feature delivery as well!

Bringing data together after painstakingly designing separation is counter-intuitive. Would you even have any of the benefits of a micro-service architecture anymore if you have one big fat database with all your data in it?

Chris will explain how, at Landbay, we maintain totally different data stores and built an awesome downstream data-warehouse reporting solution with a robust data pipeline. He will cover the Do's & Don’ts as he talks through the evolution of the data pipeline architecture, touching on many technologies as he goes, from Redshift, Glue & Apache Spark to Stitch, dbt, Great Expectations & binlogs on the cloud.

For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Luckily, there are shoulders to stand on to get out of the quagmire, or even better, prevent getting on to that slippery slope in the first place.

Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but one often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk Trond will focus on the lost art of business capability modelling. The thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when splitting monoliths into a mesh of autonomous (micro)services.

Maybe they could even help dentify subdomains, contexts, and organisational structures; in effect constructing a sociotechnical system?

We’ve all seen frontends versioned separately with tight coupling to dependent services, breaking cohesion. The rise of Backend-For-Frontend is real and so is the emerge of micro frontends. We all talk about composition, yet so many projects fail to implement actual composition. The result seem to be some kind of compromise proving hard to scale when multiple teams are involved - causing lock-step deployment, latency, bottlenecks and coordination issues.

What if you could find a viable solution that allowed you to scale development, keep distribution and cohesion and also provide composition of user interfaces?

This talk explores the different patterns available, and attempts to pinpoint their pros and cons, effectively serving as guidance to implementing proper composition. Thomas will go beyond the simple “Hello World” example that always seems to work, and you’ll learn patterns in modelling and designing that can actually be employed for composition.

Developers are moving from being purely third line support, to working more collaboratively with engineers and operational staff. Also as you move to cloud native microservice solutions, the increased complexity and diversity of our production landscape means operational staff may well rely more heavily on the engineers, in particular out of hours.

Nicky has spent the last 18 years working across a plethora of industries utilising a myriad of technology and approaches. From working on everything from trading applications to content enrichment APIs, she has seen a lot of approaches and processes try to help minimise operational support for developers.

In this talk, Nicky will be exploring and discussing some of her top approaches and techniques to help reduce the risk of that dreaded 3am call! You will gain some practical insight into how to handle failure in today's more complex distributed microservice systems. This will include looking at approaches to resiliency, understanding your system, understanding the requirements for fault tolerance, and the developers' mindset necessary for this. She will be peppering this talk with real world examples, and an occasional war story along the way too

Healthcare is no longer local; laboratory tests cross borders and radiology reading is outsourced offshore. While overwhelmingly complex, healthcare is also one of the most rewarding industries to work in, making direct impact to the lives of patients. Sonya will dive into the complexities that an architect in healthcare faces and ways to address them to create robust solutions and improve patients’ experience.

• Understanding typical challenges of the healthcare industry
• Using techniques of Domain Driven Design to shape solutions
• Managing cross-cutting concerns, such as patient safety, data security and regulatory compliance
• Supporting ancillary business functions, such as audits

During the last 8 years, at Internovus, you've found so many creative ways to do the latter:

• The different ways events can introduce coupling so strong, it will make the classic enterprise monolith envy
• Multiple ways of using events to introduce accidental complexity
• How to use events to turn a microservice into an architectural trojan horse;
• Why some events, just like underwear, better be kept private

Those sights are not for the faint of heart, but fear not. You will get heuristics that will help you identify those situations, eliminate event-driven accidental complexities, and make events great again.

In this talk Matthias will cover many of these coding guidelines, which aren’t usually covered by patterns or principles books. They should help you write better code and give you a richer vocabulary for reviewing other people’s code. Some of the subjects that we’ll discuss are: state, mutability, CQS, one-method objects, domain-first, API-driven, functional programming influences, object boundaries, (de)serialization, and more!

This talk will look at what guarantees Kubernetes gives you out-of-the-box, and what you can do to establish a trustworthy and reliable workflow for deploying and updating images. Topics and tooling covered will include:

• mutable vs immutable images
• building images in a repeatable manner
• distributing images through registries
• controlling what images can run in your cluster

But just because you cut your big scary monolith into itty bitty bite-sized chunks doesn't mean you're actually cashing in on all that microservices have to offer. In particular, this talk focuses on one fundamental question: Are your microservices independent? Microservices should be modelled as isolated units, but in reality, robust systems rely on cooperation between those different units. This seems like a Catch-22, but there is hope!

Heather will explore ways to minimise the dreaded deployment dependencies and cascading failures through a loosely-coupled client server relationship, well-defined interfaces, and automated contract testing in your build pipelines. She will also share how Landbay has cleaned up their own generated code dependencies, bolstering the resiliency and independence of their system without losing the speed and ease of normalised interfaces. Plus, it’s CI/CD friendly! To paraphrase the immortal words of Destiny’s Child, “If you're gonna call make sure it's your API you flaunt / depend on no one else to give you what you want.”

However, many of you design software for users whose native language is not English. In such cases when going through the knowledge-crunching process with the domain experts there are no English terms mentioned and both the model and the Ubiquitous Language are expressed in the native language. Then you try to implement the model and suddenly there is a dilemma whether or not to continue using non-English domain terms in code or do we try to translate them? How do you bridge the two worlds? Ignoring the issue may lead to discrepancy of Ubiquitous Language applied in code vs. oral communication and documentation.

This talk will present the challenges the teams have encountered while developing patient record systems for Norwegian hospitals, trying to code in English and communicating with users and domain experts in Norwegian. Takeaways are the lessons learned and suggested approaches on improving the model while lowering the language barrier.

The aim of this lightning talk is to arm you with ‘the benefit of hindsight’ and help you recognise the early warning signs of this anti-pattern and take appropriate steps to avoid it.

In this short talk JP will give a clear description of what quantum computers could do and could not do, as well as an assessment of the risk (is it in 1 year, 1 decade, 1 century?). He’ll then overview post-quantum cryptography mechanisms, standardization efforts, and tools available today.

Nikita is going to talk about some of the architecture design patterns that prove to be very effective when running out of resources while migrating from one infrastructure provider to another.

Entity-centric designs tend to have an uneasy relation with events happening over time. The actual business processes, the heart of how organisations operate, end up hidden in the many calls between services.

Temporal Modelling is the cure: build models and systems that make events and processes the first class building blocks of a domain model. In this talk, Mathias is going to look at how reasoning with time helps you better understand how to build your software.