Tobias Goeschel

Tobias Goeschel

Senior Solutions Architect, FSI at AWS

Bad Waldsee, Germany

Tobias started his career as a freelance web developer in the late 90s and has since worked on hundreds of projects of varying sizes and lengths - from a single person to multiple teams, from a few days to several years - and in many different roles: Consultant, crafter, coach, and... well, architect. He is a strong advocate of diversity and inclusion in the tech industry, and an active member of the European Software Crafters and Domain Driven Design communities.

Area of Expertise

  • Information & Communications Technology
  • Media & Information


  • Lean
  • Agile
  • XP
  • Software Crafting
  • Domain Driven Design
  • EventStorming
  • Software Architecture
  • DevOps

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.

Domain-Driven Design Europe 2020

February 2020 Amsterdam, Netherlands


October 2019 Berlin, Germany

Lean Agile Scotland 2019

Domain Prototyping or Design Is How It Works

October 2019 Edinburgh, United Kingdom

NewCrafts 2019

Domain Prototyping or Design Is How It Works

May 2019 Paris, France

Frankfurter Entwicklertag (Frankfurt Developer's Day) 2019

Domain Driven ... Enterprise?

February 2019 Frankfurt am Main, Germany

Domain-Driven Design Europe 2019

January 2019 Amsterdam, Netherlands

Tobias Goeschel

Senior Solutions Architect, FSI at AWS

Bad Waldsee, Germany