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.
The result?
- 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?
Imagine…
- 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
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 a solid understanding of fundamental DDD concepts (i.e. models, tactical patterns, bounded context, context mapping, bounded context relationship patterns)
- You are able to work as part of a team
- Although we will not be programming, you DO possess basic refactoring skills
- You are open to learn from other attendees, not just the instructor
- Iterating comes natural to you, you are not afraid to let go of your own ideas
- And remember, while this workshop will be helpful, improving and dealing with legacy systems is a lot of work, there are no shortcuts
This workshop is NOT for you in case you have significant practical experience with patterns such as the Bubble Context, the Autonomous Bubble, and Exposing Legacy Assets as a Service.
What will you be able to do after the workshop?
- Explain the trade-offs between the patterns identified by Eric Evans for applying DDD in an environment dominated by legacy systems
- Classify legacy systems based on commonly available information
- List useful principles, patterns, and practices from the DDD community, based on the type of legacy system you have to integrate with
- List common pitfalls when modeling, and designing systems in legacy dictated environments
- Design a small, but effective domain model for a real-world problem, in an environment with pre-existing software
- Adapt the model of a legacy system with adjustments that respect what is in place, while making it easier to integrate with the system
