DDD and Microservices: At Last, Some Boundaries!

QCon London International Software Development Conference returns on April 8-10, 2024. Level-up on 15 major software and leadership topics including; The Tech of FinTech, What's Next in GenAI and Large Language Models (LLMs), Performance Engineering, Architecture for the Age of AI, Innovations in Data Engineering and more.
Learn the emerging trends. Explore the use cases. Implement the best practices.
Register now: bit.ly/3rRgsJV
--------------------------------------------------------------------------------------------------------------------------------------
Download the slides & audio at InfoQ: bit.ly/2wPhat3
Eric Evans introduces a few strategic design concepts and explains how they apply to development of microservices, as a tool for teams trying to grow large systems more coherently. Bio
Eric Evans is the author of "Domain-Driven Design: Tackling Complexity in Software." Eric now leads Domain Language, a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.
This presentation was recorded at QCon London 2017.

[@zhou7yuan]

Why do I like microservices? [3:03]
Services and Messages [5:15]
Bounded Context [6:34]
context / bounded context
Context Map [8:03]
A-B partners [8:32]
bounded contexts translator [8:51]
Asymmetrical Relationships [9:37]
(Context Name) --(relationship)--> (Context Name)
(point toward power)
[10:17]
C A -- B (ContextMap)
C conforms A
There are always multiple models [14:41]
Models need to be clear, not big [15:28]
when design of 1 component start to go wrong [17:27]
Not all of a large system will be well designed [20:45]
mitigation [21:25]
Microservices as Context Boundary [22:49]
Interchange Context [24:20]
C,D,E -> I

[@nebojsakrtolica2755]

thank you

[@Hangar1318]

As someone new to DDD, I would have loved to see some concrete examples examples instead of A, B, Anti-corruption layer etc. What does it look like in practice? Is the "language" a proto or thrift schema for instance?

[@JosemyDuarte]

Settings -> Reproduction Speed -> 1,5X

[@kodermail]

shift+>, shift+> )

[@patricknazar]

"Just because something is popular doesn't mean it's bad" Oh man this was funny to hear.

[@tkousek1]

Thank you for this great presentation

[@pbdrus]

I'm wondering why do we need the anti-corruption layer on the A and D against the I? Despite the Eric's explanation it seems that since we have introduced the internal interaction language it becomes the part of architecture and thus our modules have to understand it without any restrictions.

[@b1ueocean]

Decoupling.
I was created to represent efficient messaging at interaction or interchange points but if everything consumes I without an AC (which translates internal A, D messages to I messages and I messages to internal A, D messages etc. with internal message schemas evolving independently) then I ends up in the same situation as A before I was created - becomes hard to change I without having to change conformers and/or partners as multiple interacting services are tightly coupled around messaging schemas recognised and in use across service boundaries.

[@prabhusingh7481]

Nice presentation

[@thatpaulschofield]

I'm having a little bit of trouble how microservice E could publish microservice A's events. Only microservice A is authoritative on those events. An event only has one logical publisher that is the authority for saying that a particular event happened.

[@nexus888]

This is all good in theory. What we need is to see some examples of how these interchange contexts. Sorry but sounds like you are proposing something very similar to a high level enterprise canonical model for common entities. If you have multiple of these then you fragment things further and have multiple mappings depending on who you talk to in the enterprise. Try for instance and explain your context map in the context of a customer entity that has a set of fields. How is this dealt with when you have transformations that doesn’t necessarily map nicely? In that case the organisation need to agree on the definition on the customer entity at an enterprise level and the rest will have to align.

[@chris.dillon]

I wonder if a bunch of GraphQL endpoints would make a good "I" node for the interchange? It's pretty flexible and would handle change well. I'm sure the answer is "it depends" but GraphQL has sort of schemaless contracts and explicit attribute deprecation without API versioning problems.

[@htondkar]

exactly what is was thinking

[@MaTeGames]

Yes, but in case of messaging we can't use GraphQL.

[@bartvanderwal6730]

@@MaTeGames Why not? Do you mean that messaging is two-directional communication and GraphQL is one way communication. E.g. post a query or a command and get the response. This just means that for two-way communication both systems have to be both a GraphQL server and a GraphQL client.

[@alexbruns4568]

GraphQL is synchronous. You’ll generally want service to communicate asynchronously to prevent things like rolling outages.

[@johnnm3207]

1.5x speed is the sweet spot

[@amotorcyclerider3230]

So slow it put me to sleep.

[@inc.1424]

Yeah, a bit, but for non-native English speakers/listeners is good)

[@gabcot03]

1.25x speed

[@imienazwisko486]

@@gabcot03 I've used 1.75 XD

[@chapultepec]

I barely understand english so Im fine with Evans' slowtalk 😅

[@sohamjoshi9527]

i understand the speed was slow.. but the content is top notch isnt it ?

[@semremal]

Everyone who speaks about microservices without mentioning their drawbacks deserves dislike automatically.