In this workshop you will learn how to apply Domain-Driven Design in an environment with a dominant legacy system.
The ‘why?’ behind this workshop
Do the corners of your mouth go up when you think of Domain-Driven Design? The ability to express behavior in your domain through model interactions. A shared language that is aimed at solving problems in your domain. The clarity of the code artefact thanks to tactical patterns.
All of these things are great on paper but how do you achieve them in an environment where legacy systems dictate what can and cannot be done?
Let's face it, DDD is difficult in an environment with pre-existing software.
- The size of the existing feature-set makes it difficult to understand the impact of change;
- The models of the system are often not explicit nor expressive;
- Application architecture frequently inhibits model driven design;
- The sheer number of modeling concepts can be overwhelming, especially for new people on the team;
- Incomplete or poorly designed test suites make safe changes expensive;
- And we haven't even talked about the practical objections like data migrations and deployments. The list goes on and on.
- Refactoring is costly and has a slow return on investment
- The inability to experiment prevents deep models to emerge
But what is the alternative? You certainly won't try to rewrite the legacy system which took a decade to build… Will you be stuck with your anemic domain model forever?!
- A small experiment to try DDD in your environment;
- With the benefits of a pure domain model: proper language, expressive, testable, focussed, etc.;
- Giving you a fast feedback loop on the underlying model philosophy;
- Acting as either a reference or fundament for future efforts;
- All without the overhead of a new application architecture
Join the workshop DDD for legacy systems
In this workshop you will be trained to solve a problem in the setting of legacy systems. You will devise pure models that can be applied in this setting using different approaches.
Together with some other attendees you will create a context map to communicate about the legacy environment. Once your team has situational awareness you can start modeling your problem. At the end of the workshop you should be able to demonstrate which of the approaches is best suited in a particular situation.
Should you attend this workshop?
- You should have an understanding of fundamental DDD concepts
- You are able to work as part of a team
- Although we will not be programming, you DO have basic refactoring skills
- And finally, you are not afraid to let go of any of your own ideas
About Marijn HUIZENDVELD
Marijn Huizendveld, a software consultant and trainer who lives and works in Amsterdam. He intentionally works for either startups or large corporates, the contrast between them can lead to great insights in how people build software. Over the past 10 years he learned what it takes to build software that solves a problem while simultaneously contributing to the bottom line of the organization.
Building, maintaining and operating a large event sourced application out of his own pocket made him realize what it takes to build a good system without burning through your resources. Marijn founded DDDNL, the Dutch user group for DDD-practitioners. In his spare time you can find him on one of their meet-ups or at home baking sweets and desserts with his son.