Speaker Details

Chris Simon
Chris Simon - Technology Coaching & Advisory
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.