Managing Domain Knowledge

From example mapping, to behaviour-driven development, to domain-driven design practices like event storming and domain storytelling, we now have a wide range of tools for collaboratively building knowledge about domains and creating models of those domains for building software systems.

One gap that many organisations experience is the management of that domain knowledge over time.  Domains evolve.  Team members learn new aspects of the domain, or invent more useful models. Team members leave - taking domain knowledge with them, and new members join but never get the chance to participate in foundational collaborative modelling.

Living documentation is a set of practices to help ensure institutional knowledge is reliable, collaborative and low-effort.

In this workshop you'll get hands-on practice with modern living documentation tools such as Contextive that help apply these principles to the task of managing that critical domain knowledge.

In this highly collaborative and hands-on workshop we will:

1. Split into separate teams who will each explore a different domain, building and capturing domain knowledge using our standard development environments
2. Shuffle team members between teams to experience helping new-comers learn the domain knowledge you have already distilled
3. Respond to an external change prompting the maintenance of evolving domain knowledge over time

You'll leave well prepared to empower your teams to skilfully manage complex and evolving domain knowledge in your businesses.

Drive Startup Success as an Adaptive CTO

In this opinionated and sometimes controversial take on being a startup CTO, I'll share with you a three step model for adapting and evolving both your personal technical leadership style - and your technology assets - as your startup grows.

These steps follow the business growth trajectory: the first is the solo/small team phase where the CTO must be technically hands-on while also contributing to strategy and business development. The second is when growing a team - technical practices need to evolve and the CTO must become the leader the new team-mates need. The third occurs when crossing the boundary to a multi-team/multi-department organisation - situational awareness, org design & process-orientation become far more significant.

This talk is Informed by personal experience launching and scaling two successful startups but is balanced with a mix of proven and emerging thinking in leadership, technology & strategy - such as Wardley mapping, socio-technical systems theory, dynamic re-teaming and domain-driven design. It is intended to support new and aspiring technical co-founders in achieving both personal and startup success in this challenging but thrilling adventure.

TDD & DDD from the Ground Up

Are you interested in using Domain-Driven Design (DDD) to create maintainable and scalable software, but not sure how to get started? Or perhaps you've heard that DDD is only suitable for complex domains - and when starting out, you're not sure if your project will need it?

Join me for a live coding demonstration that will show you how to apply Test-Driven Development (TDD) from the very beginning of a project so you can bring DDD in when you need it.

We'll start with the simplest possible implementation - a basic CRUD system to help a university handle student enrolments. We'll gradually add more complex requirements, such as the need to ensure courses don't become over-enrolled - which will prompt us to do some code-smell refactoring, strangely enough arriving at things that start to look like the DDD tactical patterns of repositories, aggregates and domain services.

In implementing these requirements, inspiration will strike! What if the model were changed - what if we allowed all enrolments and then allocated resources to the most popular courses as required so we never have to prevent a student from enrolling? We'll now see how the TDD tests and the neatly refactored domain models make it much easier to embark on this dramatic change - in other words, how much more maintainable our DDD codebase has become.

The code in this demo is available in either C# or Java - the audience will vote on the day which language is used!

Living Ubiquitous Language Documentation with Contextive

"A change in the language is a change in the model"

As you maintain model integrity you may end up with "duplicate concepts" or "false cognates".

Is everyone coding or are they coding? (Are you a doctor or a software developer)? Does a spoiler make you happy or sad (Are you a car enthusiast or a film lover?)

And how do new team members who weren't part of initial modelling exercises get up to speed on your ubiquitous language?

In this talk we'll explore a new open source tool called Contextive. It's designed for documenting the ubiquitous language and embeds the definitions in all the places the language is used - in code, documentation, online conversations and modelling tools.

It is context aware, so you always get the right definition in the right place.

And since you see the definitions where you're working in the domain, you can update them as soon as you identify need for change or improvements.

We'll explore how to use the tool including best practices, and benefits to be gained for new and old team members in capturing and evolving your language definition as part of your code repository.

What are my stock options actually worth?

For many years, tech companies have used equity compensation as a way to attract and retain technical talent - however it's not always clear to candidates what they're getting themselves in for!

This talk will explore the fundamentals of corporate finance in terms developers will understand - by simulating the design of a software tool intended to help job candidates make sense of equity compensation package offers.

We'll use techniques from the field of Domain-Driven Design to explore the problem, touching on topics such as the fundamentals of business health (profit & loss, balance sheets, etc.), business valuations & funding models, and common equity compensation packages.

At the end of this talk, you'll be well equipped to understand what the long term prospects of your future employers are and how to assess the potential risks and rewards of various compensation plans - and you might learn a bit about Domain-Driven Design along the way!

When Customers don't share a language: Modelling Deep Dive

In 2015 we launched an innovative new product into the Australian Fintech landscape - a healthcare & disability insurance claiming platform to simplify life for support providers, recipients and insurers.

It was intended that a heterogeneous group of support providers and insurers would engage with the platform - from doctors to physiotherapists to disability support workers on one side, and private insurers & state or federal government departments on the other.

Although the high level process for each of these groups was similar, the extant rules, terminology and UX scenarios varied.

In this talk, we'll do a deep dive of the modelling journey we went on, starting with aligning the model with our first customer, evolving it with our second, and radically reinventing it with our third.

We'll explore how the context map evolved from being aligned with user channels to being aligned with insurer subdomains and how we balanced the tradeoffs between specificity and genericness in the tactical pattern implementation within core domain contexts.

Modular Monoliths & Microservices - A 4+1 View Continuum

Over the last 7 years we used the 4+1 Views to design a system as a modular monolith - saving time, cost and complexity when the team was small & load was low and allowing simpler realignment of module boundaries as we were still discovering the domain. We gradually extracted modules into microservices as needed once we had built confidence in boundaries, when load grew and as the teams expanded and needed autonomy.

So how does it work?

The 4+1 views is a way of understanding systems that uses 5 different 'views' of the system, allowing to design and scale different aspects of the system in response to different triggers:

1. The logical view represents functional requirements & scales with functional complexity
2. The process view represents executable processes & how they interact & scales with concurrency and deployment requirements
3. The physical view represents the hardware & networks that the processes execute on & scales with load and throughput
4. The development view represents the system as seen by developers (e.g. code) & scales with the number of teams and team size
5. The scenarios view represents the various scenarios in which the system is used & highlights how components in the other views interact

A modular monolith is a system that has 'scaled up' the logical view (multiple modules), but not scaled up the process or physical views (single process, single hardware configuration).

In this talk we'll explore what went well, mistakes we made & tips for adopting this approach.

Winning at Continuous Deployment with the Expand/Contract Pattern (Live Demo)

You've done everything right: you have a continuous deployment pipeline, you have a commit stage with great unit tests, a pre-prod stage with fully automated deployment, robust end-to-end tests as well as some performance & security checks, and once all your quality gates are passed, your stream of changes march confidently towards production - but then somehow, someway, somewhy, production still blows up!

Continuous delivery is awesome, but the devil is in the details, and there's a decent chance you've been bitten by one of the biggest challenges - the safe management of contract changes.

Contracts can be obvious and public such as APIs (URL structure & schema), or obvious and private, such as database schemas, or non-obvious, such as the schema of in-flight messages in a queue, or dependency on specific timing expectations.

This talk demonstrates with real deployments the fundamental principle that underlies all safe contract changes - the 3 step model:

1. expand - introduce the change in a backwards and forwards compatible way
2. change - ensure all instances of the component and all dependants are using the new definition
3. contract - retire the obsolete compatibility elements

The good news is, with continuous delivery we can often do all three steps in quick succession!

This has been delivered at Voxxed Days Brussels 2023 and Agile on the Beach (UK) 2023. It includes a live demo where we do a deployment of a contract change in a single step while running an end-2-end test in a loop. This test fails during deployment, and we then re-do the deployment in 3 steps and demonstrate that the tests never fail.

Domain Driven Design and Serverless: A Winning Combination

Domain Driven Design (DDD) is all about aligning software design with the business domain, helping developers build systems that accurately reflect real-world processes and requirements.

In this talk, we'll explore how to apply DDD patterns in a serverless context. Specifically, we'll look at mapping bounded contexts to serverless components, managing long running processes (aka sagas) and using serverless messaging capabilities for practical event-driven architecture, including a comparison between event streaming vs message queues for DDD-style business events.

Whether you're an experienced DDD practitioner or new to the concept, you'll walk away with valuable insights and strategies for building better software using these complementary approaches.

Learning to Love DDD - a Tale of Two Products

Over the last 16 years, I've been fortunate enough to launch two successful businesses as a hands-on CTO/co-founder & developer/architect.

The first, Flexischools, provides online services to schools & parent communities, and has supported millions of Australians over the years.

When we launched Flexischools, I was relatively inexperienced - I did my best to follow the guidance I could find online, but I frequently found myself struggling to incorporate the burgeoning growth in complexity of its feature-set into an increasingly tightly coupled code-base with a very small team of developers.

In 2015, I discovered DDD, and when reading the Blue Book, I felt a light bulb going off on every page. When we launched our second product, LanternPay, I vowed not to make the same mistakes.

LanternPay is a healthcare & disability claiming & payments platform supporting hundreds of thousands of Australian care providers and recipients to ensure prompt and equitable access to care.

In this talk, I'll reflect on the comparative experience of launching, operating & scaling both products and the impact DDD had on the technology & the business.

Some key questions we'll explore:

* How to use DDD when you're launching a new product into a new market and there are no domain experts to consult?
* Why it's not a good idea to use the same object/table to store both the size of a school uniform t-shirt and the presence of a slice of cheese on a sandwich
* How to make the business case for a major multi-service refactor when your DDD-inspired domain understanding evolves mid-project