Skip to content
Home » Podcast: Avoiding Legacy? DDD, Collaborative Architecture and Product Thinking with Nico Krijnen

Podcast: Avoiding Legacy? DDD, Collaborative Architecture and Product Thinking with Nico Krijnen

Do you hate legacy or do you love it? Do you accept it or do you want to stamp it out? This time I talk to Nico Krijnen (Lumunis) about the opportunities we have in our legacy codebases to understand our business better, the strategic use of new technologies to make important product improvements, the importance of collaboration and visualisation to create a shared vision of software architecture and our product no matter what state the codebase or architecture.

We discuss the meaning of legacy, what it is and when it appears, how to fix it, how to avoid it and how to prosper as a business while replacing it. We also talk about what you can do in your pipelines to avoid legacy automatically, the importance of visualisation, context mapping in DDD and C4 diagrams.

In a fascinating and wide-ranging discussion, we talk about what it takes to make great software in the age of microservices.


The DDD NL meetup:

Nico’s workshops at DDD Europe:

Full-day workshop on June 6:

2h hands-on at the main conference:

Automating architecture validation for Java and .NET:

With an example of using it for a layered or onion architecture from one of Nico’s workshops:

Nico’s speaker profile & linkedin:

And an overview of some of the courses Nico gives through Luminis:


[01:41] “it seems that in our industry, only seniors and architects, et cetera, are getting in touch with domain-driven design at some point and I think that’s a waste” [NK]

[02:10] “so one of the things I really wanted to do is trying to lower that learning curve [for DDD]” [NK]

[04:03] “you need to have ways to create sort of a shared mental model of the stuff you’re working on” [NK]

[05:02] “We had a chat the other night about, how we feel about Legacy. I said, I love it and you said, I hate it. How does the legacy fit into to your daily work?” [RB]

[06:20] “legacy can have a lot of bit different meanings, but typically it means something that’s not, at least how I see it, is it’s a code base or a product that’s not easy to work with anymore.” [NK]

[06:38] ” I like to go fast. I like to, to build stuff and, and be excited about those things and not feel dragged down by, a big stone that you’re dragging along.” [NK]

[06:47] “that’s why I hate it [..] but to be honest, all our industry is full of it” [NK]

[07:03] “a lot of teams do not have the discipline to then go fast, but also go quality” [NK]

[07:45] “So typically when you meet a legacy system, first of all, what, what are the smells of its legacy? And secondly, what would you start to think about doing to improve that situation?” [RB]

[08:59] “we got someone in and they started working fully automated regression test, so deploys to production could be done, [in] half an hour. So that’s different from a week, right? ” [NK]

[11:16] “Cause it’s a system that’s making money, right? This legacy system is the place where, where you, where your business runs on.” [NK]

[11:55] “So, I still hate working with legacy, right?I refuse to accept it. I think that’s more than mindset, right? So I refuse to accept it as legacy.” [NK]

[12:50] “You can transform that into a modulith like, which is, uh, what you call it nowadays.” [NK]

[14:09] “So that’s also why I think why I’m talking at conferences and spreading this knowledge because I think it’s important to help the industry to realize this and also to find ways to get [legacy] under control” [NK]

[14:23] “We’re building more and more software and, if we’re not doing it the right way, we’re just building, a lot more legacy. And I don’t want to be there!” [NK]

[15:06] “I think the ease with which organizations now adopt Kubernetes and under underestimate the complexity, [is] quite scary, to be honest.” [NK]

[16:46] “I think in a lot of cases people underestimate the value of just sticking with the stuff that you know and can handle” [NK]

[17:34] “Because I think a big portion of legacy is that people don’t understand how the system works or what it’s supposed to do, or at least do, or pieces of it.” [NK]

[17:49] “I think that’s where domain driven design, again, has a good role to play, is that it helps you to understand a domain. It helps you to understand the problem space.” [NK]

[18:24] “it’s good to use some experimental technology to do something that nobody else has ever done because it’s gonna put you in a space where nobody is and where you can solve problems that nobody else can solve.” [NK]

[19:56] “I would try to take the Frankenstein out of it, not accept that it’s a lost cause.” [NK]

[21:00] “[Legacy] is usually the point where people don’t understand how a system works anymore” [NK]

[22:25] “In the workshop you encounter something that’s called an Arc Unit, which allows you in your pipeline check or you compile time or test time, check that the architecture that you have in mind is not violated” [NK]

[24:08] ” I think is always super important to have at least one visual in your, in your project” [NK]

[24:53] “try to write the minimal amount that you can, right, that you need, but that you are sure that you can keep up to date over time” [NK]

[27:43] “the real value of that kind of high level diagram is not so much having an up-to date version of it. Is it It is drawing it together with the people working on it.” [NK]

[29:11] “giving context , about a system, what I think is really useful to draw a context map like from DDD, which essentially is like the high level context overview of, a system, but then more focused on the communication patterns between systems and especially also between teams” [NK]

[30:24] “a high level C4 diagram and a context map” [NK]

[31:05] “The temptation is always for everybody to prove their worth on any project” [RB]

[31:50] “we don’t want to get the impression [of domain driven design] that it means you start to do a lot of design upfront.” [NK]