Introduction to Context Mapping - Michael Plöd - DDD Europe 2022

thanks for having me everyone isn't it good to be back at conferences again in a room packed with people so I'm super excited for that and yeah thanks for showing up in those big numbers uh to my talk on context mapping and this is not going to be uh a PowerPoint Bonanza kind of a talk um I want to make an engaging talk together with you so usually I would tell you toss away your smartphones and store them in the bag and just listen to me but no pull out your smartphones and you can join

this talk yeah and I will have a bunch of live questionnaires and feedback stuff on that so you can participate in the talk and while I do that I want to give you a personal notice this talk was very very short of being canceled why because the wife of my mother has passed away over the weekend and she was always excited when I was traveling to conferences and she she always said oh is there another video of you giving a talk and oh those many people so I want to dedicate this talk to Marianne rest

in peace and um yeah just a few words about myself I'm Michael plut I work at a company called innocu I would say I'm quite engaged in the DDD Community for quite some years and this context mapping thing is something that always I I think caught my attention to a certain degree and um so I want to give you an introduction to that but before I do that I would like to you to give me an indication about your knowledge how would you rate your knowledge on domain-driven design in general boundary context context maps and

the the standard software architecture stuff like cohesion coupling modularity and so on so how would you rate your knowledge in that area foreign I see quite of a quite folks having a decent knowledge yeah mid knowledge about EDD of course we're in the foundations track boundary context not so much cohesion coupling yeah also present but context maps not so much so you're in the perfect talk here yeah so because I will give you an introduction uh to context maps and before we do that I want to revisit some Basics Robert Frost's once said good fences

make good neighbors and you may wonder why yeah I um why I bring up this quote and let me just Smash in another quote um or another idea by Daniel Daniel H pink who wrote a book about what motivates people and it's he came up with the idea that it's about autonomy Mastery and purpose and isn't that something that we want to achieve with teams in an organization isn't this autonomy thing something that appears again and again and again and again in the agenda of this amazing conference here yeah so how do we achieve that

yeah one of the ideas yeah that we very often see in the DDT space is that we say hey we need some decent boundaries in which teams can achieve and we very often say autonomy but also let's expand this idea to Mastery and purpose and one of those ideas is the idea of the boundary context and in order to guide you there yeah Maxine my good friend is also doing a talk right now in the Red Room about this Beast here about the domain dream design starter modeling process and that's something that I want to

really give you as a first very very big hint yeah um check out this GitHub repository it's all Creative Commons yeah you can copy stuff from there you can use it on your own own it's a community effort by many folks who are doing talks and workshops at this conference yeah including me as well and we will very strongly focus on this middle part here and yeah one idea is there the boundary context so this starter modeling process guides you at moving towards good context boundaries and then moving to code with tactical design and a

perspective on bounded context which I personally like quite a bit is that the boundary context is a boundary for a model expressed in a consistent ubiquitous language and which is tailored around a specific purpose you remember that Daniel H Quinn Daniel H pink thing there was purpose in that we have purpose in here as well it's an interesting take so let's dissect this briefly before we actually get into context Maps so boundary context is a boundary yeah like a module a module is all also supposed to be a boundary around a model and a model

yeah in the DDT perspective is a behavioral model yeah containing it's all about business rules decisions certain policies in a consistent language a language consists of terminology definitions and meanings a widespread example for that is for instance the Tomato what is the tomato a fruit or a vegetable yeah most people will probably say it's a vegetable because you take a look at that from a cooking perspective who would expect the Tomato to be in a fruit salad I would be a little bit of a strange fruit salad maybe yeah but from the Botanical perspective of

biologic tomato is actually a fruit if you take a look into the time management context maybe someone of you works with the time management method Pomodoro a tomato represents a unit of 12 minutes of 25 minutes of uninterrupted work and if we go back to the Medieval ages where theater plays were on marketplaces in this context what is a tomato that is flying to the stage negative feedback so I hope I don't get any flying Tomatoes my direction here today but I don't see any tomatoes around here so I'm relaxed um and it's aimed at

a specific purpose so we want to do things ever the language the rules and the specific model are tailored to a certain purpose so we don't want to do this thing where we're maximizing reusability no matter what and let's build a USAA a fruit a cooking botanics time management feedback tomato no let's build specific models here yeah and when we take a look at yeah this thing this boundary context there is a very new perspective as well which is I would say three years old now yeah posted by the amazing folks Matthew Emmanuel from the

team topologies book they said hey maybe it's a boundary context can also be seen as a team first boundary and I said yeah we need boundaries in which teams can achieve autonomy Mastery and purpose but so far what we have is a very static view on this matter yeah so let's define a boundary let's aim towards a purpose yeah let's have a dedicated language for that but how about the Dynamics between those boundaries now that's missing here yeah that's that's something we can't see here and obviously on this talk I need to come up with

the good old Conway's law quote Yeah any organization that designs a system defined broadly will produce a design whose structure is a copy of the organization's communication structure yeah it's in from Melvin Conway's paper how committees work a very very amazing piece yeah a great paper and the thing that gets very often misunderstood here is that Conway's law is not about the org chart yeah which is also a static view on things now it's about the Dynamics in that org chart yeah it's about the communication structure what I'm always sometimes choking around a bit is

I would say yeah I would also take a look at the four floor plan of an organization which teams sit next to each other's and which teams share a coffee kitchen with each other because what's happening in a coffee kitchen communication yeah and I think that's a dynamic that's a perspective and I think communication can be in a high bandwidth way where two teams talk a lot to each other or in a low bandwidth way where there is not a lot of talking between the teams and this is ever the context map basically comes into

play also a quote from the team topologies book as an architect you should be thinking which team interaction modes are appropriate for these two teams what kind of communication do we need between those two parts of the system and between those two teams so again here those Dynamics yeah and that's something that um is very old in in domain room design context maps have been in the blue book by Eric Evans which came out I think 19 to 20 years ago or something like that so that's old stuff that's nothing revolutionary that's nothing new this

stuff what I'm going to present here has been around for all this time and I think I always say that context maps have been a little bit of a Hidden Gem in the uh in the in the DDT space yeah everyone has always been looking at the Tactical patterns like Aggregates and also the Strategic stuff like boundary context subdomain subdomain categories and stuff like that but I think there is a lot of value yeah in this perspective and I would say let's um let's dig into that yeah and yeah what kinds of relationships between systems

and teams do context map address let's check this out a very simple and a very obvious perspective yeah is you have a bunch of systems or you go a little bit deeper into boundary context depends on the granularity of your deployment unit and they call each other I think those are perspectives that we have seen all the time yeah I think in nearly every office where some software Architects have been sitting you have probably all seen those big printed a0 Pages like this is our complex system landscape this system is calling that and they call

that and they call that and most of the time no one was working with that it was just a poster to show we're dealing with complexity here yeah and being a little bit sarcastic or we published some events and those are reacting on them I think this is a very widespread perspective that everyone has seen But there are more perspectives to that another perspective is the propagation of models on every one of those interfaces you will get a certain model so when you call for instance the Google Maps API you will obtain a model from

Google about a point of interest about the root and so on and that's first of all Google's model now what are the consumers doing with those models huh are they just copying them into them are they transforming those models yeah so in in this example here yeah where we have a German credit rating agency called the shufa yeah they where you can get a quote hey how credit Worthy is Michael for instance yeah is he a credit worthy person or oh better stick away from that guy yeah with the long hair yeah maybe let's not

do business with him yeah and they answer with that in that in in that model yeah on a synchronous call and you may now say ah we're doing event-based microservices and we worked with Apache Kafka we're decoupled per definition because we're just doing those things no you're not because you can still do the whole model propagation thing in an event-based system yeah so you pack the credit application form into the event and then copy it further and again you have a high degree of coupling that's a very interesting perspective which the context Maps also address

and then yeah we have some communication things yeah between teams there's communication going on for instance one team the credit agency agency team says hey we'll adjust the interface and the underlying model with the next release the other team says hey no problem yeah just send us the documentation we'll cater for that we'll adjust our code so that nothing breaks or you have a different kind of communication so we're going to deprecate that domain event and replace it with a new one in the next release and the other team says I know hey stop you

can't do that we don't have the time we don't have the budget and by the way the risk is too high for us and if you do that we're going to escalate that to the management so we're raising a veto here yeah that's also a very interesting team perspective yeah and yeah you can also have a perspective where one team does something and it has an impact on another team yeah and so for instance yeah the credit agency will replace the web service by some restful HTTP resources next week and it has an impact on

the bank they need to do something and they may not be very happy with that and the credit agency couldn't care less about that oh their problem not ours yeah but when the bank changed some of their scoring rules doesn't matter for the credit agency at all yeah so now let's go into into the first very specific context mapping thing so those four perspectives yeah um dependencies between teams communication model propagation providing of apis yeah they are being addressed by the context map and the first thing that the context map addresses are certain dependencies between

teams one dependency is a mutual dependency yeah so let's say I am a team and you are a team yeah when I do something you need to do something as well and when you do something I need to do something as well yeah so we have a mutual dependency obviously the both of us we will have to talk a lot together yeah we need to coordinate our efforts we need to coordinate our testing maybe infrastructure and so on and so forth so um we are highly coupled so to say but on the other hand yeah

if you take a look at the let's say the calendar teams from Apple Google and Microsoft now iCloud Calendar Google Calendar and the exchange calendar by Microsoft I would say those teams they are free yeah I I we don't have a global yearly calendar software release day where everyone needs to address their calendars that would be horrible that would be something for the evening news or something so please update your calendars or everything will break that's not going to happen but nevertheless I can send a calendar invite to you you you you and you yeah

and I'll probably do that yeah because as this Inner Q we're sponsors of DDT Europe and in the goodie back of DDD Europe there is a voucher for a free Hands-On context mapping session remotely with me on July the 5th and if you sign up for that you will get a calendar invite from my exchange calendar yeah and they don't care if you have a Google Calendar an iCloud Calendar or anything like that yeah I don't care about that so those teams they are free and then we have the Upstream Downstream dependency so let me

pick someone else oh let me grab you so I do something I do a code change and it doesn't affect you you don't care yeah so I changed something you couldn't care less but when you change something it affects me I need to adjust something let me give you a concrete a specific example for that so um let's say we have one team which is responsible for filling out an application form for a mortgage loan a complex form four pages you need to provide a lot of information and then we have a scoring team which

which is responsible for a scoring bounded context and when you change that form it will probably affect me and my scoring rules because I need to change something in there but when I change some of my calculations you couldn't care less think about the rivers yeah I live in the city of Nuremberg in Germany and there is the river called the peakness floating through our city and our neighbor City foot yeah um is Downstream of Nuremberg so when I toss a small boat into the peakness and place a case of let's say alcoholic and non-alcoholic

beers on that boat and the boat floats from Nuremberg to third it affects food so they can grab a cold one yeah and they will probably be very happy but in soccer or football however you call it there's a big rivalry between the teams now what would rather happen is that the people in Nuremberg there's a high degree of rivalry between the cities would toss something really ugly in the picnic yeah and and the people in food they will be helpless because they are Downstream yeah so Upstream Downstream is also a lot about power dynamics

not between teams the Upstream teams has a lot of power whereas the downstream team yeah is sometimes helpless at the mercy of the Upstream team so the context map in addition to that contains nine patterns yeah and I will walk you now through all of those nine patterns yeah to describe those relations in a greater depth so don't worry I will try to make that I mean usually explaining patterns can get pretty boring and dry and so on I will try to do that as entertaining as possible for you because I don't want to kill

all your energy in the in the second slot of the conference already yeah but please bear with me let's start with a very simple pattern called the open host service I would say that's a very easy to understand pattern so we have one boundary context yeah or a microservice and it provides an API an interface yeah which provides others with a certain set of functionality yeah the important thing is the boundary con the open host service yeah is an API an interface that is tailored to many consumers yeah not to just you or you or

you no it's an API that is there an interface that is there for all of you people yeah think about the Google Maps API That's a classic open host and also in high utilization of most servers so usually yeah on a context map you visualize this openhost thing with a visualization called OHS ah there I have it there I am it's called OHS open host service and now since you're all yeah or most of you are newbies to context mapping there is a very big heuristic for you in 99 of the cases maybe with some

additional lines the team providing the openhost service is an upstream team yeah because they have a control over the openhost service so if you leave this talk and apply that stuff in practice next week yeah but please know career finishing moves with that stuff yeah and you say the open hole service is Upstream you're probably right now I've seen very rare cases where the openhost is in the downstream and that included very powerful Regulators ever a regulator went to a bank or insurance company and said okay you need to provide us with this interface we

Define this interface we Define the roadmap we Define the quality criteria for the interface and you just provide us with that yeah because then the power dynamics change yeah the team which implements the interface actually has no power over the interface so that was when the openhost service moved to the downstream team but that was in I would say I'm doing context Maps now for 13 15 years or something that was the only case that I've seen so far with the utmost service move to the downstream team now every and this Upstream Downstream relationship yeah

you see the D that stands for Downstream and you see the U there that stands for Upstream yeah so we have an open host service being provided by an upstream team and we have two consumers on that who are in the downstream now with every open host service you provide a model to the downstream teams yeah in every openhost service there is some model with some data being provided and now let's switch sites let's go down to the downstream team now they can do something with that model and we're now moving into this model propagation

relationship that I've described early on I would say 10 minutes ago so one strategy that the downstream team could apply is they can Implement an anti-corruption layer what is the anti-corruption layer all about first of all it's visualized as ACL anti-corruption layer in the context map so context maps are a visualization technique as well and they are uh as a dictionary of certain linguistic elements yeah of terms yeah they they there are certain names for relationships but you can also visualize those relationships with context Maps yeah and the ACL is basically a model to model

transformation so we provide yeah through the openhost service a model and the downstream team then goes ahead and transforms that model to something that suits their purpose think about the boundary context definition again yeah we want to build that is expressed in a certain ubiquitous language tailored to a specific purpose now that's what's happening down there in the scoring part that's their purpose that's their Vision so we have a model to model transformation there yeah um however yeah an anti-corruption layer you may think that's a great idea that's what I want to do every time

but please be aware there's also effort involved that you need to implement this and you need to maintain this so this costs you time and money an alternative for that would be you say ah screw this I I don't want to do that effort thing yeah I don't have the time I don't have the money and I don't see the urge to do that I become a conformist what does the conformist do so they take the model from the Upstream team and they just take it okay they just work with this yeah conformist is visualized

as CF yeah con formist now um this is easy a conformist is always an easy choice this is fast but it leads to a higher degree of coupling yeah now let's talk about this coupling thing now this is a I would say a simplified version of of something you could call a hexagonal architecture only an architecture clean architecture I know there are certain differences but the the general idea is very similar between these things now let's see how deep the coupling of those two patterns goes in these architectures in the conformist you couple yourself directly

up until the core yeah the domain model of your architecture so your coupling goes very deep into your application and a widespread misconception regarding the anti-corruption layer is that it is about decoupling in my eyes there is no decoupling yeah when systems have a connection together we have a loose coupling anti-corruption layer is about loose coupling because we limit the coupling to the outer yeah rings of this application usually on the adapter level yeah so um if you talk about coupling the coupling of the conformist goes deeper yeah into your application you need to change

more and the the impact of the changes of the conformist is ways higher ever as on the anti-corruption layer you prefer a looser coupling and the impact of the changes usually ends at your adapter level now I think something that is now in your heads and I think that applies to most of the people most of you will think now having a conformist is utterly stupid idea I think that's too simplistic it depends yeah that's usually the question there are some heuristics where a conformist may be a good idea yeah so for instance you have

one boundary context that provides computations that are highly regulated yeah you don't want anyone else to mess around with that or you can use a conformist to give certain teams less power or more power as well yeah so or you just want to save time and money because you say hey that external model is good enough for me I have built some amazing conformists and I was super happy about those conformists they worked they did the job yeah mostly in not so strategic areas and I avoided the extra effort now let me let's pull out

your smartphones again yeah you may rejoin this talk or join again I think most of you are still in the talk so I'll give you a second to pitch in because we will do something now which is also posted on this DDD crew site there is um a GitHub project called context mapping quiz which has been provided generously to the public domain by Nicktoon and Gene Versace who are both here as well so make sure to check out their talks and props to them and I will give you a scenario now please take a look

at this yeah and please go ahead and there are yeah I would say some comments about this context map and I would like you to choose which ones you see fit foreign so let me show the results quickly okay so a lot of you voted for lots of cross-team collaboration needed yeah and propagation of models through many contexts yeah and basically yeah those two here yeah um you you made the absolute right choices here so what can happen yeah that you will have a hidden coupling between models here in this scenario so uh the coupling

yeah it can trickle down it can start from here yeah we have a coupling of some stuff that is here in there and then yeah this model from down here can also be propagated down there through another conformist and suddenly yeah you change something in here and a totally nasty Park pops up over there and everyone is surprised oh how could that have happened I think you've all been in those situations haven't you I've been on those situations countless times and I cursed like hell when I was supposed to find out where the bug is

until I had to find out oh it actually happened over there yeah you can visualize these things and now imagine you doing a big I a big scale I.T transformation you want to revamp an ugly historically sometimes hysterically grown monolith I think you want to know these things yeah how this provocation happens in here yeah let's move on to a different pattern the shared kernel that's even a stronger coupling than the conformist yeah with the shirt kernel I physically share an artifact with someone yeah so let's say this conference patch here is a jar file

a Char library in the Java world or you can use a dll or an npm module whatever you want to have so I'm a Java guy I'm one of those boring dudes who's still doing Java and um yeah so that's my share to our file and oh there is a different system here yeah and that system is sitting over here can you grab this as well yeah you so we have a shared kernel yeah we are physically sharing an artifact here so when I pull you fly over there and when you pull I fly in

the audience you can lose it yeah thanks so I want to decouple myself from you yeah and um so that's the shared curl the shared kernel can be is usually visualized as SK shared kernel yeah no surprises here and um it is a high degree of coupling yeah it can happen through shared artifacts or dear historically grown monolith you love that so much of a shared database schemas maybe with some store procedures in them yeah a good stuff yeah High degree of coupling yeah and um so basically yeah this is a clear warning sign if

you wanna build wanna use domain driven design to build microservices or self-contained systems or anything like that avoid shared kernels you don't want to have that in this area nevertheless there may be some heuristics where a shirt kernel can come in handy yeah it's always an it depends thing yeah so for instance yeah you have one team being responsible for two or more boundary contexts which which have a certain overlap in terms of language yeah you may now think oh but that's not clear cut DDD yeah but that's the reality in most projects yeah that's

what I see all the time and I I think we can't always optimize for absolute Purity Yeah in our modeling sometimes we have to deal with trade-offs that's our reality yeah and please also take that advice when you go away from the conference into your day-to-day job yeah you will see you will get inspiration at the conference for many great ideas but you will not be able to apply everything in Perfect Purity into practice that's reality yeah we need to deal with trade-offs so this may be a trade-off yeah um but always avoid shared kernels

when two teams are in a competitive relationships yeah so for instance your uh car maker an insurance company a bank and you have two external vendor companies yeah so we have one external vendor yeah that's those rows sitting here we have another external vendor those rows sitting over there and they are in a competitive relationship at your place do you want them to share a share to have a share kernel hell no you don't want that because you will have this thing will become toxic yeah this will be a play ball for political Foul Play

for political games for a bunch of nonsense that you really don't want to have in that situation yeah so one thing when two teams have a share kernel they have to form a partnership that's another context map pattern actually yeah so with a partnership yeah you don't want those teams to be in an enemy ship yeah you want them to have a partnership so that they coordinate their planning their development they need a joint management for integration testing rolling things out yeah highly dependent highly recommended for teams that have a shared kernel is that a

team dependency that I want to have when I want to move towards autonomous teams or highly autonomous teams probably not but moving yeah from highly dependent teams to autonomous teams never works like boom oh I've been a tdt Europe and tomorrow we do autonomous teams yeah it would be so please don't think that no that's a a long-term plan that takes months and years and you need to move to that state in stages so this can also be used that you visualize where you are currently at where you need to address certain things in that

area yeah so this can also be seen as visualizing a status quo and having some terms to describe a certain status quo so that you can move away from that yeah so please see that as well from that perspective and I have another question for you which comments apply best regarding to the team in the middle which has a lot of partnership relationships to the other teams on the outside so let me show your results so obviously that team sits in a Hell lot of meetings yeah they are living in meetings so to say yeah

they don't get any work done yeah because they they are stuck in in they can't even drive their own agenda yeah because they need to coordinate coordinate coordinate I tend to disagree that they are in a powerful position yeah um maybe that can apply very rarely but in practice I've never seen that happening yeah because they are mostly driven by others and it's hard to prioritize things for them yeah um another pattern yeah that also um is a very interesting one is the customer supplier relationship between teams what do I mean with that customer supplier

only happens in Upstream Downstream relationships yeah so when you have this power difference that you have a very powerful Upstream team and uh yeah helpless as Eric Evans said it in his book supplier team now let's take a look at this example on that slide we have one team which is responsible for the form where people can apply for a mortgage loan maybe some of you have applied for a mortgage loan yeah in the past years I'm pretty sure and I'm pretty sure that this wasn't the nicest user experience around and you have to fill

out a lot of crap for the bank and they wanna you need to let down your pants and they want to know everything from you in order to be able to assess the risk so and then we have the scoring team yeah which computes a score where we say we would Grant probably Grant a credit to Michael or not now that's a clear Upstream Downstream relationship but now think who is actually responsible for the complexity of that form is it really the credit sales funnel team that owns the form because if if I think how

are they driven they are probably driven by mortgage loan applications brought in yeah so hey whoa we we gained a hundred applications for a mortgage loan yesterday that's great and we were able to increase that metric by 20 over the last three months that's great how could they do that by having very simple forms however there is another team that says huh we are really sorry but we need more data in that form in order to be able to assess that risk and that is the scoring team now they are Downstream usually they can't make

that claim now what do we do we introduce a customer supplier relationship we say okay we allow the scoring team some influence and what is very important some influence on the planning of the Upstream team so we give them the allowance that they can go to the let's say there is a contract for that so they can go once a year to the credit sales funnel team and tell them hey we want those in two new fields in the application form but you can toss the other one we don't need that anymore for a certain

new scoring rule or they can do that when they have a new requirement by an external regulator yeah when external regulators come up with something they always need to fulfill that yeah so we give we Grant with the customer supplier relationship we Grant the downstream team a certain degree of influence on the planning of the Upstream team so we strengthen their Precision a little bit clinical pattern this is an organizational pattern yeah you can't see this pattern in code yeah however there is also an empty pattern variant to that and I call that veteran customer

and helpless supplier yeah that's the customer down there that usually doesn't come up with new requirements new ideas but that's just the this this customer down there that says oh no we don't have the time oh no our risk is too high yeah so that's to a certain and and they have the power to block the other team in doing stuff yeah um take a look at that context map here so we have one supplier and a bunch of customers in the downstream which statements would you consider to be valid for this scenario what do

you think right so let's hide the image and show your results yeah that team is obviously driven by customers yeah they can't drive they can't master their own thing think about this autonomy Mastery purposing I think that's also not an autonomous team yeah um and they will spend a lot of effort in prioritizing things I think they will make no customer happy at all you know that's plain impossible yeah um now what we had was should introduce an open host service in addition to the customer supplier relationship that brings me to a quick hint an

open host service is usually aimed at um a variety of Downstream clients now when you start adding customer supplier relationships to an open host service you may end up in very difficult situations so hint from my side as a future scenario I would usually avoid customer supplier relationships against upmost Services because I want to have strengthened the team that is applying yeah this interface this API that should solely be owned by that team especially if you have a mixture of an open house service and some teams being in a customer supplier position and others being

not in there yeah you have the a remote control I will show you a scenario later on which addresses in exactly that and that's where I would say from my perspective the correct answers would be those over there yeah you should introduce an open host service instead of those customer supplier relationships I think that's a way better idea there all right now a pattern which I will mention briefly is separate ways yeah this is a pattern that you only have in the team relationship in the team dependency free you remember the calendar software example yeah

those teams they went separate ways but there is also another twist to this this can also be seen yeah as something where you don't have a technical integration between two systems yeah because this is expensive this causes a lot of effort and you'd rather go with manual processes to address that yeah so um let me give you an example I see that very often in call center systems of systems yeah very often so you have the call center agents and they work with three or five systems in parallel when they get a call and they

enter one system copy data and then alt tap alt tap alt tab I already see someone laughing here and doing this so and then pasting the data in there again yeah that happens very often so there is no direct integration between the systems that you can't see in the code no this is an organizational integration now when you are transforming it Landscapes you want to see that yeah you want to be able to describe that because when you change something and this doesn't work the call center may break a situation where you probably don't want

to be in yeah so that's separate ways yeah and then there is a pattern um we only have two more left yeah so we're getting to the end of all these pattern descriptions which I consider to be very interesting but which is also in my eyes rather vaguely described in the blue book and also the red book a rap book by Von Vernon that's called published language so pre-definition the published language is a well-documented language which is shared between boundary contexts and from which boundary contexts can translate in and out of that so for instance

why are those calendar teams from Apple Google and Microsoft so independent because they work with a published language called Icelander you you know those dot ICS files in your emails and those are data files that were that provide data in a certain format and everyone can translate in and out of them yeah so that makes those teams independent now the vagueness here yeah is in the way um how you see that in correlation to an open host service for instance if you take into the Publications by one take a look into the Publications by Warren

Vernon he only has images that show a published language next to an open host service so you see many images OHS PL yeah which stands for published language so that may lead to the understanding that an open host service always has a published language yeah I mean I I know the perspective for this is coming from so in the moment you publish a part of your own ubiquitous language through the openhost service so that's one perspective that you can have um I'm very honest and this is my personal opinion here yeah so that's not backed

up by a book or anything like that maybe expect for my own DDT book um I think I expect from an open host service to have a well-documented interface and a well-documented language so I think that's something that I expect as a part of a definition of done for an open host service yeah I don't want to have an interface that says oh just go with it and do whatever you want with that I think there is no added value I think a published language and that's how the way I use it I would see

those patterns also as heuristics so that gives you some flexibility how I treat that very often that this is something like a standard where there's a Committee involved of some teams yeah I mean for eye calendar there is a standard the RFC for eye calendar the same applies to vCard when you send your the telephone number of your best friend to another friend yeah so and I would say this is the published language here and that's a perspective that works very well with me so if you want to get into the Calendar app business you

can get started right away with the big names you just need to apply or Implement that published language which is I calendar and you're good to go when you really have the greatest calendar app in the world someone will knock on your door do you want to sit in the committee yeah you're doing good stuff we'd like to have you in there where you buy yourself into that committee yeah and you get an influence on that so I would say published language is a little bit more so for instance the the the model from the

Google Maps API in my eyes is not a published language it's just Google's model which they drive which they influence yeah which they publish over there openhost service if you do the same you'll probably get sued by Google yeah and that's something you probably don't want to be yeah um now the last pattern I would say is a pattern that we have all at least once in our career built on our own but of course only in our previous jobs not at the current employers yeah because at our current employers everything is perfect and we

are not building a big bowl of Mater yeah so everything's perfect in our current employment that's from our dark past yeah um that's a pattern that one added to the red book and I would say personally I'm not so sure if this is well placed in the context mapping session section yeah so that's a part of a system where model boundaries are not clear where the language is wishy-washy awake and this is mostly a warning sign so you don't want to have a shared kernel with an open host service you don't want to conform to

the model yeah or let's say the spaghetti mess of a model of optimal service you want to have ACLS against openhost Services yeah so let's sum this up a little bit in my eyes you can visualize different perspectives with context maps and you don't need to visualize all perspectives at once so if you're just interested in a certain perspective you just pick the patterns from that perspective so you can start off with core relationships something you probably already have yeah and then you can take a look at the first level in team relationships or team

dependencies Upstream Downstream for instance yeah you can say oh where do we have apis where are openhost services how about the model propagation yeah with anti-corruption layer conformist and so on and yeah finally a deep dive into team relationships where do we have Partnerships where do we have customer suppliers and so on and these patterns yeah they map to certain different perspectives as well yeah and um also to team dependencies so for instance partnership share kernel is something that you usually see in mutually dependent teams three teams very often work with with published languages separate

ways yeah an upstream Downstream is something that you very often find with customer supplier anti-corruption layer conformist openhost service so there is also a mapping on that yeah and also keep in mind the team communication yeah so shared kernel customer supplier conformance they are high communication bandwidth patterns we have a high degree of organizational coupling whereas the other ones yeah they are more tailored towards a lower communication bandwidth yeah now let me show you in this example again we have an almost service with a bunch of anti-corruption layers looks great doesn't it Now One customer

is always vetoing changes on the openhost service what happens if the system's X and Y are dependent on those changes for the development of their further features and functionality and product increments they will get blocked in their progress because of set saying no the risk on the openhost service is too high for us I've seen that as a piece of a political Foul Play sorry because one manager there was a round where someone some of the mid-managers was about to get promoted and so this manager from system set was always saying no no risk is

too high for changes and then in the interviews for the promotion round told the HR department well I get a ton of releases out I get my stuff going but the managers for from X and Y they don't get stuff done yeah they always need to postpone yeah why because he was blocking them indirectly yeah something we actually found out by drawing context Maps yeah he didn't get promoted so let's take a look at a more complex thing yeah check this context map out here so I call this context map the model propagation from the

gates of hell yeah why so what can happen there so we have a rating model which moves through a conformist into the scoring boundary context and then we have another shared kernel and it can propagate probably to the credit application thing and the same can happen with the customer model as well oh ugly stuff yeah that's not so easy to fix yeah so that's not a quick fix you want to know that when you want to revamp your application landscape this is high risk stuff here I would start by breaking up the Shaker kernel first

yeah probably now there's one more thing that I want to give you we with subdomains and we have those two main categories maybe you heard about core domains supporting subdomains generic subdomains yeah maybe you have found a context sitting in a core domain which is super important we have other ones in generic subdomains that are not so important where you don't have a lot of passion for yeah um there is also a helper on the DDT crew site that can help you with this stuff yeah and as a last exercise for you I would like

you should ask some questions yeah should a generic or a supporting subdomain be a customer for a supply and a core domain yeah um how to deal with a big ball of mud in a core domain conform it to other categories and so on yeah so that's not so uh not so easy stuff and to wrap this talk up as a last thing I have this scenario for you what are your thoughts on a core domain conforming to an external system what do you think you can write some text here I'll give you half a

minute is this a good idea bad idea very dangerous hell yeah hella ain't a bad place to be maybe there are some ACTC fans out there it's a song by ACDC need to implement an anti-corruption layer weak to position to be BN yeah so let's see pin there it's hell other domains bleeding into your own quarter Mania bad idea stupid idea depends but generally bad yeah this is a utterly bad idea yeah because why you're dependent on the agenda of the provider of the external system in your core domain that's the last thing you want

to be in a core domain there you want to drive your own stuff yeah and that's an Outlook yeah as an Outlook to these things we're getting to the end of the session there is also a different perspective on that and I know there are a bunch of talks on this in the main conference as well maybe you want to check out the team topology stuff by Matthew Emanuel you can greatly combine team topologies and context Maps as well to get an even better Insight yeah on these things and yeah two more resources I think

you definitely should check out the context mapping project on the DDD crew site on Twitter there I have provided for you a context mapping cheat sheet under Creative Commons yeah which you can print out on big paper and whatever when you do want to work with that with definitions and visualizations and there is also a a starter kit for my row where you can get started with context mapping right away yeah so you can download the port backup it's creative comments do whatever you want with that yeah and you can get started there's buttons and

stuff for all the patterns in there and if you want to dig deeper and there's even bigger parts of that context mapping quiz also published on the DDD crew site on GitHub yeah so I took out some examples from that in this talk but if you want to get deeper and play around with your own team get your hands dirty that may be a good starting point yeah and maybe yeah so you're interested in applying that stuff to you I I will do a free two-hour context mapping online session on July the 5th for all

attendees of DDD Europe the voucher for that is in your goodie bags because Inner Q is a sponsor so please sign up to that and I will also publish the slides on speaker Tech of that talk so you can refer back to them and yeah you can follow me on Twitter I'm also on LinkedIn um I do trainings and Consulting on all these things so if you're interested in that you can hit me up and I'll be around at the conference till Friday late afternoon so you can come up to me with questions and remarks

and feedback and so on and for the time being I want to thank you very much for the attendance and I'm glad that the questionnaire worked out with our slides thanks for participating in that and I wish you a great rest of the conference please enjoy DDD Europe thank you very much and here is Eduardo