Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021

[Music] so let's start by talking about my topic the main driven design i think that one reason you you attend this talk or you watch this talk is that you know what that is but in case you don't i'm going to spend a few minutes on explaining my understanding of domain driven design i promise not to make this too long basically what i what i will try to emphasize is what i think the core contributions of the main driven design are as sven said because in fact despite the title i do like the concept i

do like the community i do i like many of the members of this community and i like a lot of the contributions so let's talk a bit about what domain driven design actually is so this is my attempt at to me this is an approach to designing software that puts the domain at the center and that seems to be something that should be completely obvious this should be the only way to build software after all why would you build software if you're not building it for the domain it's intended to serve right it seems completely

obvious but as you can see i'm an old person i've been in this business for a long time and i have been part of a group of people that loves to play with technology and i've seen lots and lots of projects that were based around a particular technological logical effort around some tool that were motivated more by the interest of people to play with cool stuff as opposed to focusing on the domain so i think that is the core idea in the main driven design and another thing that i consider to be a core part

is that what others in other communities consider to be something that should be separate from the software is a core part or is the essential part of the software in the mandatory design namely the model so the idea that the model that you have of your domain actually is the core of the software system that you're building the the the main concepts that you typically express in the model are actually visible within the code that implements that domain logic that's the other key part that those are the two things that i consider very important of

course i'll give you the official definition as well this is one from from eric evans's domain driven design reference so eric evans is the author of the original book which came out i think in 2000 something 2003 or so so um in one of the updates to the to the terminology he gave this definition it has a lot a lot in common with with what i just said so focus on the core domain another important aspect to him is the collaboration between domain experts domain practitioners and technology or software practitioners so we should work together

and we should have a shared understanding to arrive at this ubiquitous language which is the idea that you have a common set of words that you don't have to translate between the terminology the software people use versus the one the domain people use as a software person should be your goal to capture that language to help the domain experts clear up the language and make it a core part of all of the concepts and components and building blocks that you have within your software system so is that a good thing or not i think this

is a completely good thing we probably can all agree that this sounds very good and i i definitely do think it sounds very good when i read the book i had an interesting that was a long time ago as i said when i read the book i had an interesting feeling that i that i've learned to recognize as something good and that feeling is well yeah that seems obvious if you read a book and what's written as seems to seems to be very obvious then that's often the case that somebody took the time to actually

write something down in a cohesive a logical fashion that should be common knowledge but often isn't it might be obvious to you it might not be obvious to other people not everything might be obvious to you only parts of it might be and establishing this shared understanding is i think a very good thing i don't think eric evans would claim that he invented tons of new things i don't think he ever did that what he said was he he derived a pattern language he came up with a way talking about things that was to him

best practice at that point in time and the key aspects in the book that that you know resonated with me were were three things one was this ubiquitous language that we already talked about i think that's that's an excellent concept it changed many things for me made me made me want to invent new terms less made me want to understand why the main people used the language they used so i think that's a very good thing and it's a very very useful thing to have this agreed upon language the second contribution of the book is

one that i'm going to talk about a little bit more slightly later on which is this idea of tactical patterns now if you're building software it doesn't really matter whether you do that in an object oriented fashion or not but especially if you're building object oriented software then you are familiar with certain patterns such as a value object or probably an entity object those things were around before the book came out they're not an invention by by domain driven design but they are a key part of the book they may actually make up a major

part of the book and they serve as a set of patterns to help you structure and design your software system so entity object value object service repository factory those were things that were had been there before module as well it was elevated to the same level as a pattern here things like aggregate were a little more i wouldn't say obscure but a little more novel but this was essentially the language if you will that that eric evans came up with in his book and again this was not something that was completely new to me we've

been using similar terms in many projects i know that many other people were at the same time so it was um basically giving good names or assembling things with good names that were common use that's a technical view on the whole thing and after the technical part actually there's another quite different part with this which is the strategic part of the main driven design in that book and that's i think also an extremely important to me actually the more important part of domain driven design it also has a number of patterns a number of concepts

with names like for example the bounded context which means the key concept here and a number of patterns for the relationships between banner context and the teams that help build the software that implements that context i'm going to explain the term context a little bit more in the next slide but the key idea that i want to want to get across here is that again the book and the and the domain of design concept contains a number of those things which are good and useful things to talk to use when talking about relationships between contexts

and teams so what is this bounded context thing that we're talking that i was talking about abandoned context essentially is well a context within a certain part of the ubiquitous language or if you will a certain ubiquitous language holds true so look at this example here if you think of a larger system then very often you end up decomposing it into let's call them modules or subsystems or packages or building blocks within those building blocks things may exist that seem the same as those in other building blocks so in my example here you see a

product and a customer in my three different bounded contexts here with an order management and accounting and fulfillment those content concepts exist and they do have a relationship but they're not the same if you consider what a customer is from an accounting perspective that's mostly financial thing it has financial relevance whereas a customer from an order management perspective is more related to you know creating an order and maybe tracking order status and having some kind of i don't know customer information to propose other things for them to order whereas in the fulfillment domain the key

thing might be the shipment address and the way they want their package delivered these are just examples right but the point is that within those contexts you uh you get you get a certain level of isolation by agreeing uh what the what the what the domain terminology means within that particular context as opposed to overall which is sort of the uh sort of the the absolute nightmare of every of every person who has to build software in my view which is that somebody went around the company and asked everybody what do you think that a

customer is what do you think that customers what do you think and then adding attributes and responsibilities to a god-like customer object that then that some poor soul would then have to implement because trying to come up with one customer that serves everybody's needs is surely going to end up in a disaster so this idea of separating things again was not an invention of domain-driven design but it got a very cool name and a name that stuck this bounded context concept is to me the single most important concept within all the main driven design and

the one that i really love to use in lots of places so that all sounds good i hope i hope you don't think that i wanted to you know paint things in battle i didn't want to do that so i think these are all valuable contributions and useful things so let's talk a bit about the problems that i have with some of those things so the first one is that i really value conceptual extensibility i i really like this idea of having a language right so the idea that you have this language that you that

you can use to talk to talk to others about certain concepts is a very valuable thing if you can agree under the main language that's really cool but if you consider what the main language is on our level you know on the designer level then there's certain you know a certain way of uh of meta level here right so let's think about this if we generalize this whole concept and this ubiquitous language also exists on the level of software design so the patterns that i showed you themselves could be a ubiquitous language right the patterns

that we're talking about other patterns of software design within the software design domain we have entities and aggregates and values and contexts and partnership relationships whatever right those are our that's our language right well the the interesting thing here is that the same that i that i that i claimed was true for the domain that we typically think of is true for our domain as well would you really expect us to be able to walk around every software project in the world and come up with the one set of patterns that matches all of them

i for one wouldn't because software projects are very different i mean they have they have they have different contexts right the context actually are we as software developers so i think this idea this language should really be more of a jargon kind of thing right it's a jargon within a certain context within a certain community so let's assume that all of us here work within within a larger software project where may be distributed across several teams then we have our own jargon on multiple levels we have words that have meaning within each team we also

have words that have meaning across the teams so for example the ways we figure out on how to integrate our stuff or how to do frontends or how to access the database or perform network communication right those things are ways that we come up with and that change over the course of time once we discover a pattern we actually use it so the key thing that i want to get across here is that the set of predefined patterns is always only a starting point it's not an end in itself i don't think that eric evans

ever wanted to claim that the set of patterns that he came up with was the one and only set of patterns that could ever be useful to anybody of course why would he claim such a thing he's a smart person but some people take it extremely literally literally they think that these things here are the pattern the patterns if you do the main drum design then you have to use these things these things only and you have to use them in exactly the way that the book describes them whereas my view is that this might

be a great starting point they might be perfectly fine for you but you also might have with your own language you might add filters and rules and proxies and contracts roles reference whatever it is that makes sense within your jargon within your context language right so whatever makes sense to you you add at this level so that essentially means we're extending the the technical patterns but of course the same is true for the context relationships as well so if you think of what these if you if you're familiar with them what they do if you're

not a briefly explain them what they do is they they tell you the ways that contexts might be related for example one context owned by one team might be um simply conforming to whatever interface another context prescribes you have no say in that they're more powerful than you that you find something that may be an outside company or a standard product whatever they tell you the contract is is the contract that's the way you ex you access their services or their interface whatever it is they offer to you right so that's one way of a

relationship another might be a partnership where it's more of a negotiation between equals or the relationship might be one where you actually share a code where you have a common piece of code that that is that is available and used in both contexts right maybe not a good idea but that's not the point the point is that you can describe this relationship if it exists and that's again very useful it's a cool thing you draw a context map you visualize those dependencies you can reason about them you have some ways of dealing with them so

for example introducing an anti-corruption layer as a means of isolating yourself against changes those are all very good ideas but again they're a starting point right you might have something like a formal contract that might mean something very specific to you you might have a shared spectrum a third party standard or whatever it is whatever kind of pattern makes sense to you again you should be able to extend this as you see fit so my criticism is not that the patterns are bad i have some issues with some with some of them i'm not a

big fan of the aggregate pattern but whatever i mean that's a discussion we can have if we ever work together in a project but whatever makes sense to you within your project should be the kind of terminology and the kind of language that you come up with in fact we used to do this in a domain that is really really not cool anymore it's really not fashionable anymore and it's the model driven community the model driven architecture remodel driven development community right so if you're if you have gray hair like me then maybe you remember

that that was once a really cool thing i don't think it's bad just because it's no longer fashionable i don't think it's the i don't think that is the solution to everything either not at all but what i want to point out is that back in the day when we did that we had we had a similar concept we had a language a meta level a way to express models with certain stereotypes in for example uml it was the same idea it was the same concept it's on the you know from far away this looks

extremely similar to the whole thing so that was my that was my point number one that i wanted to make the second one is about what domain driven actually means so i mentioned that um i like the idea of being driven by the domain in fact i have a slide from a different slide deck that um that talks about this common disease among developers i hinted at that at the beginning right domain allergy that's a that's a common thing weirdly enough i find it it's it's especially prevalent among software architects i don't know why i

think software architects love to play with stuff they love to figure out how technical technically complicated things work so they sort of flee from the domain into the i can say that because i am a software architect myself right so i'm always dissing myself as much as anybody else so the this idea that you can that you can avoid uh getting to know the domain by you know taking refuge in in technology is kind of a sad sad thing but it happens and the mandarin design wants to do things differently and that's to be applauded

one of the ways it wants to do this is by having this very pure thing at the heart of the software system that you're building so if you're developing in in an object-oriented language saying java or scala or c-sharp then then the idea is that you have this piece of code that really only has the main logic ideally it has no dependency on any outside technical aspect at all so whatever it is that your system needs to interface with right so there are some examples like some kind of document store the network the database the

user interface whatever it is all of those things are external to your domain kernel your domain logic right this domain logic in the center can live while can can continue to provide value while the outside interfaces change and the connection is made by a port so you have certain ports certain expectations typically so your domain code might expect that there is something that can maybe talk to others and then some implementation of that will connect it to an actual an actual network interface as just one example right so those these adapters that are sort of

from the outer perimeter here they they sort of translate between the technical details of some specific interface and the pure beauty of your internal model and you've probably seen this under different names right so the shapes here suggest this is this is a hexagonal architecture the name suggests sports adapters that's basically the same thing um you've also probably seen it as clean architecture i haven't written it here but i think it's basically not really different from a good layered architecture but i'm willing to argue that debate that point if you want to at the end

it's not not very important to me the key aspect to me here is this this this wonderful idea this wonderful idea of having this this really valuable code right this this really business focus the main focus pure code now if i were a mean person and i'm not then i would show you this slide i'm going to be very brief with it right so i mean sometimes you figure out that your actual value lies somewhere else i mean this is something that might not look as cool if you draw a diagram but sometimes you find

out that there's a lot of actual value going on at the database layer or the user interface layer or some other layer of your application and the domains logic is actually not that fancy but the domain logic only provides if that's how kind of song sounds weird how can the domain let me rephrase that the domain logic is always the most important part but sometimes the domain logic is not best implemented in a pure object-oriented core model sometimes there are better solutions for implementing your domain model so i think these are two different ways of

talking about whether or not something should be domain driven or not right so should design be the main driven well yes of course every design should be driven by the domain should not be driven by technology but if you understand something different when you hear domain driven design then i will say no not every server needs to be built using a technology neutral object oriented core again this does not mean that i have a problem with any of that i mean i like object orientation maybe not as much as i did 20 years ago but

i still like it i think it's a good concept and again if you look at the way people's people programmed and sometimes still program small talk today then i think they had these same concepts they really had they had this idea of ubiquitous language they wanted to capture the main concepts within the classes and methods messages they sent they built beautiful systems that had a lot of these a lot of these attributes so that is a cool thing and something that you can absolutely do but you don't have to do it every time so let

me offer you some mix some alternatives or some other ways you could go about building your domain logic one would be god forbid actually using your relational database this might come as a surprise to some domain driven design practitioners but relational databases are actually pretty cool pretty mature technology they're very very useful if your application is data driven then actually modeling your data in terms of tables and views and relationships between them indexes for key constraints and and all of that you actually end up with something that's really really maintainable that really really has super

high performance because it does what a database is good at so sometimes this might be an excellent choice for your application in fact i've seen and been confronted with a lot of applications that naively wanted to implement as much as possible within the oo layer and made it and had disastrous performance because they created tons of n plus one problems when interacting with the database did lots of things in memory that could have been done on the database layer created lots of problems all in the name of a better architecture and it's kind of weird

that you want to do the right thing that you want to follow a clean architecture and ends up with an ups up with something that's actually pretty dirty because you end up having to tweak and do lots of little tricks in some places so again this is i'm not suggesting this is the best model you know there's a there's a there's a guy i really recommend called lucasada on twitter you can find him very easily he writes the jooq library which is fantastic to access the relational database as a relational database as opposed to hiding

it behind some fancy ooh mechanism and he's somebody who would say this is almost always the best you can do so if you wanted that if you want that opinion follow him i'm just pointing it out at as one very useful opinion that he could have and that you could use okay so shawna rewrites that he's also seeing that approach lead to really thorny data integrity telling just that's that's true i mean this is i'm actually not not sure whether sean's referring to the one i'm proposing here or the one i propose is an alternative

because it's true it can be true in both right it can be true in the hybrid approach as well as in the pure relational approach so you'll absolutely have to watch out what you're doing here and i'm not a fan of giant messes of pl sql stored procedures in some messy oracle database either right so it all has the replay has its place okay so that was number one suggestion number two drive it from the ui drive it from the user experience drive it from the user i mean sometimes you're not in the phase where

you have stable domain logic and domain experts to talk to because domain experts don't exist yet because you're building something completely new maybe you're building software for a startup that needs to figure out what it is that the market wants you're definitely not in a phase where you're creating a stable model for the next decade that you will use in terms of applications you're in a phase where you want to iterate really really quickly build something that and get it in front of actual users as quickly as possible i would say user interface matters much

more than many architects think and i think user interface the actual way you connect to your to the actual domain users is a way of viewing domain driven as well right i think is this is actually what's most important to your actual end users so you should should assign a lot of importance to that again is this the only thing of course not so consider it as something that you might be might want to do in many many occasions personally i think that front end development and user-centric development and ui development doesn't get the credit

it deserves in large parts of our industry so i think we should invest more everybody should know a little bit of that so um probably you should do more rather than less of this but again i'm just pointing it out as one particular alternative that you could use to this domain driven or o core design thing but maybe that's not your thing maybe you're not maybe you don't really have a user interface issue here maybe you have a really really complex piece of business logic maybe it's really all the all of the complex relationships between

the main concepts that really really create the value here so maybe then the domain driven or o design core is the right thing or maybe you could go with this one this is an alternative um i had the pleasure to do two podcasts one in german one in english one with my colleague last super one with mike did i do both i think look at it both in english for the case podcast so um they both suggested something that actually is way more mathematical they're both very much into functional programming so their model is you

you try to map your domain into a into a a cohesive grammar cohesive algebra that really connects the concepts using rules that actually make mathematical sense or similar to something that you are used to from from other mathematical branches and then you actually discover new domain concepts by applying the the logic within that algebra right so if the something is combinable according to your rules you try that out and that's that's maybe something that you've never that no domain expert has ever thought of being able to be combined but once you do that and talk

to them look could we do it this way they say oh wow this looks kind of cool we didn't think of that so we actually abstract things to a different level you abstract things to this mathematical model which i'm pretty sure won't have entities and aggregates and value objects right that's a different way of designing a software you maybe have different ways of permutations or common combinations right thanks then for the link in the and the chat regarding the post the podcast episodes so this might be an option or maybe you want to go with

this one maybe you have you don't have the single the single deployment chart you don't have the single software way of expressing your things maybe you're in a domain where your programming language that that's available to you isn't powerful enough to do that maybe you don't have an o language at your disposal maybe a programming in c or an embedded system right or maybe you have to program the same thing for multiple environments so maybe you will go with such a model driven approach where you actually end up having a model separate from the software

because that is what gives that provides the most value to your specific scenario i'm not suggesting that any of these things is better than this domain driven oo design or domain driven design core right not suggesting that in fact i think domain driven design actually has a great solution for this concept which which is this this concept a context concept so i talked about those contexts if we look again at the definition of a bond of context an abundant context is something where a particular model is defined and applicable so in my example that i

had at the beginning at the beginning of this presentation i had these three bounded contacts with the order management model the accounting model and fulfillment model that all have their own validity within that particular context and you could view that and extend it to include the choice of technology right you could decide to implement things differently within each of those contexts and decide that the relational model works best for your accounting scenario here whereas the ux driven one works best for the order management and the tactical ddd one works best as an implementation strategy for

the fulfillment domain i don't really care this is just an example right this is no this does not attempt to actually suggest that this is a good choice for those for those particular kind of context i'm just pointing out that you don't have to do things the same way in all of those comics so is the idea overrated i think that that strategic ddd is an excellent starting point in fact i use that almost all the time sometimes i call it strategic dvds sometimes i don't use that terminology sometimes i use the word bounded context

sometimes i don't in fact i've been doing that for far longer and the main driven design exists which is not supposed to sound like an arrogant statement or mean that domain of design does not create a lot of value i think it creates a lot of value in this regard so this is a good thing tactical ddd i use slightly less favorably i think it's a good starting point as well but it's best viewed as a micro level decision i mean this is one way of implementing systems and it's really on a different level i'm

i'm not sure it should be part of the same discussion right this is this is a different thing you can do actually you can build excellent systems in a domain driven way i think or you can claim that you're doing domain driven design even if you don't ever use any of the stereotypes mentioned in the technical dvd part of the book or in any of those discussions i really appreciate ddn's community right i want to make that clear i like the people there i respect them a lot i have fantastic discussions with many of them

some of my colleagues are very local parts of that community and that's that's perfectly fine i'm not i don't want to you know do the typical these these guys are all stupid and i knew it all along not at all but i think sometimes there's the tendency to view this one solution as the only viable one which sort of leads me to my summary right i think just in general as general advice no matter what the particular topic is you shouldn't be looking for just one thing maybe that's something if if you're just entering this

this domain then it will take a while if you've been here for a while you probably know that already pretty sure you do no single approach no single approach will will match your needs in 100 of the cases or even 50 of the cases right everything you learn is an addition to your tool set and something that you might be able to use you might know some things very well others not so well but still you should have a large tool set to be able to choose something that matches the particular needs unless your day

job is being a speaker at conferences that who talks about one particular topic i mean that's a different thing then you can pick one and just stick to that but if you're a general purpose practitioner who builds actual systems for a domain then probably you need more than one approach recipes are fantastic starting points so specifically especially if you're starting something from scratch and don't have a lot of experience then you might want to follow the recipe more closely you might some dogma might actually be valuable right that part of your learning curve it's the

same as with a cooking recipe right when you're doing it for the first time you probably follow the recipe more closely than when you're cooking the dish for the tenth time then you'll do a lot more variation depending on your character you might start the first recipe in a completely different whatever it doesn't really matter right so the the following rules at the start is fine but don't continue to be dogmatic in the long run and i think to me the most important thing is use those contexts which are the most valuable contribution as sort

of decision spheres use them to give you a boundary within which you can decide differently from all the others and that's i think a very useful thing to do and will help you with a lot of decisions okay that's all i have you