In this workshop you will learn how to apply Domain-Driven Design in an environment with a dominant legacy system.
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 artifact 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
- 2. 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 Domain Driven Design & Legacy Systems with Marijn Huizendveld:
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.
Working together with 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.
Learn how to:
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
Available datesDates coming soon
Our team is happy to discuss other options with you.
Contact us at email@example.com and mention ref:
Private tuition and large-group discounts are also available. Find out more here.
Who should take this workshop?
- 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.
- You should have a solid understanding of fundamental DDD concepts (i.e. models, tactical patterns, bounded context, context mapping, bounded context relationship patterns)
- You possess basic refactoring skills
- Not all legacy is created equal
- Useful patterns, principles, and practices from DDD
- Situational awareness with context maps and event storming
- Bubble context pattern
- Anatomy of an anti-corruption layer
- Autonomous bubble pattern
- The impact of a service level agreement on our design
- Synchronization approaches and patterns
- Outbox pattern
- What to stick to within a bounded context
- Exposing legacy assets as a service
- Expanding a bubble
- Common pitfalls with DDD and Legacy