Chris is a technology coach & advisor empowering technology teams to drive business success. He has a particular focus on helping startups realise their vision and new CTOs flourish in their roles. He also supports executives & boards with strategic technology advice, and engineering teams with training, mentoring and consulting in architecture, quality, domain-driven design and test driven development.
He is a regular meetup & conference speaker (NDC, KanDDDinsky, Serverless Days ANZ) and to support teams using Domain-Driven Design, he recently launched https://contextive.tech & co-founded the DDD Australia meetup.
He is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (recently acquired by NAB).
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.
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!
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.
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 domain complexity
2. The process view represents runtime processes & 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.
The speaker has never seen the deck they are about to present, and is told the subject matter just before the clock starts ticking.
20 slides will auto-advance every 15 seconds.
What could possibly go wrong?
Searching for speaker images...