Test Driving Your Domain Core

Depending on your chosen platform and implementation model, keeping a domain core thoroughly tested and prepared for late-project changes can become tricky and cumbersome:
Tying your tests too closely to the implementation can make them brittle and costly to maintain, integrated tests are hard to change and keep useful - just to name a few common issues.

In this workshop, you will:
- Get a quick introduction to Outside-In TDD
- Test-drive an OO implementation of an aggregate and repository
- Learn when to mock and when to use collaborators
- Experience the effect of Tell-Don't-Ask
- Find out what happens when we introduce CQRS and EventSourcing

Prerequisites: A solid understanding of Java, JavaScript, or your favorite object-oriented programming language (though this may mean you will have to translate the examples, sorry), and a laptop with ready-to-work IDE.

Domain Driven Design in Cloud Native Environments

When Eric Evans wrote his seminal Blue Book, he could hardly have foreseen the advance of cloud computing, infrastructure as code, and managed services. Many of the original and well-established DDD patterns at first glance seem inadequate, unhelpful, and strangely misplaced in cloud native environments. Even the power of micro services, and their strong connection to bounded contexts, is waning, as the industry standard shifts to serverless functions, and low code or no code development tools. How much of DDD is still relevant? Can the same mechanics and heuristics help to guide us through a vastly different landscape? A story about finding familiarity in a strange world.

5 Ways To Take Your Enterprise To The Cloud with Domain Driven Design

Traditional enterprises are faced with a dilemma: Volatile markets and increasing pressure from fast-moving startups are forcing critical systems into the cloud, while existing infrastructure, culture, and millions of lines of legacy code make necessary changes slow and painful. While business demands faster delivery, IT strategists are looking at 10-year plans and multi-million dollar investments to even catch up with the competition.

Efficient navigation and high-impact decision-making are key to achieve sustainable modernisation of valuable assets, and successful reinvention of business models. To join the game now, instead of leaving the field to the competition.
Domain Driven Design is a powerful enabler, both as a strategic compass, and as a framework for execution. This talk presents 5 ways to start transforming today -- from where you are, and with what you have, and to see results in weeks or months, rather than decades -- based on real life scenarios and customer stories.

I Have 99 Problems - Where Do I Start? The Theory of Constraints Applied.

Your IT organisation is surrounded by problems preventing it to respond to market demand on time with the required quality. Where do you start?

35 years ago, Eliyahu Goldratt introduced the Theory of Constraints in his seminal book "The Goal" as a new management paradigm to running manufacturing plants. Back then, manufacturing plants had similar problems: The production work floor was surrounded by inventory, resulting in late deliveries having poor quality. The Theory of Constraints solved that problem for manufacturing by introducing five focusing steps - a guideline to systematic improvement and continuous learning.

Today, the Theory of Constraints is one of the underlying foundations for the DevOps movement. It hasn't lost any of its potential for organising thought, and as a driver for continuous improvement.

During this session, we will present the basic principles of the Theory of Constraints, and how it applies to the software industry. It will be a mix of theory, related stories and experiences, and practical advice applicable to the day-to-day work of an IT department.

Domain Prototyping or Design Is How It Works

When we design a system from scratch, especially complex distributed systems, with microservices and/or Big Data pipelines, we have to make a series of important tactical decisions regarding the structure and information flow within our domain. If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy. Some of those aspects are hard to discover upfront, and even with great experience, it's not unusual to get the first design at least partially wrong.

One way to minimize the consequences of those decisions, and to verify our initial assumptions, is to start implementation not with a full architecture in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe and explore - and change easily, if we run into problems. This way, we can actually see our design work, and gain valuable insights. As a side-effect, we can also deliver customer value much earlier, by using the raw domain model to power UX/UI prototypes - replacing fakes and click-dummies with a working application.

Using concrete examples, I will demonstrate how combining Domain Driven Design with the practices, heuristics and principles of Software Crafting can highlight difficult or problematic choices, improve fundamental architecture decisions, and ultimately lead to better and more sustainable software systems, long before we get sidetracked by the additional complexity of host environments and deployment pipelines.

I presented this as a 2 hours hands-on at DDD Europe. There are no slides, but there is a github repo with exercise instructions, which should convey the idea.

It turns out, 2 hours are really not enough for most people to grasp and apply the concept - and that detriments the value of a hands-on significantly. That is why I chose to turn it into a talk, instead: I can present some examples and give a “guided tour” in much less time.

This talk is for advanced practitioners.

Choking the Monolith - The Strangler (Fig) Pattern Applied

The so called "Strangler Fig" (aka "Strangler") pattern is a much cited strategy for replacing legacy systems with new, often microservice-based architectures. However, it's not actually a microservice pattern, and there are several - quite different - ways to implement it.

Are you confused yet?

Fear not: We will have a look at the theory, and then explore together, how Strangler Fig could be used to improve and replace a project worthy being called "The Most Horrible Piece Of Code in the World".

Domain Driven ... Enterprise?

Domain Driven Design has become a widely accepted, if not the preferred method of conceptualizing and implementing complex software systems.

But when we talk about aggregates, bounded contexts and ubiquitous language, we often only have the scope of a single application / system in mind: We analyze the business, and ideally use the results to implement a runnable domain core to build a product around.
In more complex domains, there can also be more than one: Subdomains and peripheral systems need to be included - a distributed system is the inevitable outcome.

Both these scenarios allow us to build solutions from the ground up -- lean, cost-effective and customized to the business needs. In some cases, we might have to integrate or replace one or more legacy applications in the process.
For all of this, DDD provides well-known patterns, frameworks and solutions.

But what if even a single business process involves an entire company, with complex hierarchies, sign-offs and auditing, reports, and data protection concerns? What if existing processes aren't isolated, but span a plethora of systems with acronym names, implemented decades ago, by authors long since retired? What if they were written in forgotten languages, without the slightest idea of DDD in mind? What if real-time events must co-exist with end-of-day batch processing and asynchronous file transfers? What if the company's usual IT project is planned and budgeted as "Connect SAP to CRM"; its purpose and business value all too often lost in translation?
This is the ugly reality of large corporate enterprises, all too often embedded in politics and a dysfunctional culture. And they _really_ need our help...

Starting with some real-life "war stories" and anti-patterns, I will show examples of how even in the most old-fashioned corporate setting, DDD principles, patterns and architecture can serve as a guiding light towards a better and more sustainable infrastructure, and fundamentally benefit not only IT departments, but the entire enterprise.