SkillsCast coming soon.
The Domain-Driven Design experience-paradox
Did you recently learn about Domain-Driven Design, and are you excited about the potential to express domain-knowledge in code? Do you get inspired when reading sample code that showcases how capable a rich domain model may become?
Eventually your initial optimism about DDD will be superseded by a difficult question:
How would I achieve such a rich design for my own domain?
Turning a model into a well functioning design can be quite a daunting task, especially when you lack practical experience. When you get started you may quickly find yourself asking various questions:
- Where do I start?
- When should I apply the tactical patterns in my design?
- How should I discuss and evaluate design trade-offs with other people?
- When should I sacrifice purity of the model and the design for progress?
- How do I apply a specific tactical pattern in my programming language of choice?
- Am I doing it right?
There is good news, practice makes perfect. As you gain more experience you will learn to focus on the domain itself, and worry less about doing things according to the book. You will know to judge a model by its usefulness. As such, the best shortcut is to get your hands dirty: wax-on, wax-off. Challenge yourself to model small problems to hone the skills required.
Unfortunately you cannot gain experience in applying Domain-Driven Design without putting thought into the domain itself. Sure, you could get started with the tactical design patterns to create a blog, a user-management system, a CRM, or a to-do list, but without the capriciousness of a real domain and a real project you'd be fooling yourself. You need something smaller and you need something more relatable to your day-to-day work.
A DDD-traineeship at Carries Cars
Imagine you recently joined 'Carries Cars', a car sharing service that started operating in Amsterdam 6 months ago. Carries Cars operates 300 vehicles that are spread out over the compact city center. Owning and operating a car is expensive and Carries Cars is on a mission to make car ownership a thing of the past.
In this workshop you will model and design Carries Cars pricing engine. In doing so you will:
- Get coding quickly in a pre-setup project
- Experience the benefits of Value Objects
- Leverage testing as a tool to discover design details
- Evolve the model and design as new requirements come in
- Contrast different implementation choices with other participants
- Learn about the trade-offs of the programming language of your choice
The workshop program
Homework prior to the workshop (90 minutes):
- Install the sample project
- Familiarize yourself with the domain
- Research implementation styles in your programming language
- Evolve the model with new aspects relevant to pricing
During the workshop (session of 120 minutes):
- Compare your work with that of another participant
- Pair-program on additional functionality
- Visualize the model using various techniques
- Discuss trade-offs with other participants
Should you attend this workshop?
Regardless if you are eager to learn DDD or if you are hesitant towards it due to your personal beliefs, the best way to evaluate something is to try it.
As a courtesy to your fellow attendees, do make sure that you come prepared in case you decide to join this workshop.
How it works
- Within 72 hours of signing up for the workshop on you will receive an email with instructions for the homework.
- You will submit your homework to a GitHub repository.
- During the workshop you will pair program in break-out groups using Zoom.
- Modeling activities will take place in a shared Miro board.
Make sure that you are able to:
- Use an IDE for automated refactoring
- Write a test in the programming language of choice
- Run tests from your IDE
- Commit and push code to a private GitHub account
- Collaborate using your own Miro account
- Try to make yourself visible on camera during the interactive parts of the workshop
- Take care of yourself by having access to some drinks and light snacks
- Be mindful of your impact on other participants: bring a headset to prevent bad audio and find a quiet space to limit noise
YOU MAY ALSO LIKE:
A DDD-traineeship at "Carries Cars"
Marijn works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as freelance developer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, little money). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event sourced domain models in PHP and has been actively involved in the DDD-community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. He also laughs at his own jokes, for reasons unknown cause they typically aren't funny. Join the session to see if you agree.