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
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?
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.
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.
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.
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.
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.
@@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.
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
thank you
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?
Settings -> Reproduction Speed -> 1,5X
shift+>, shift+> )
"Just because something is popular doesn't mean it's bad" Oh man this was funny to hear.
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.
Thank you for this great presentation
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.
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.
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.
Nice presentation
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.
exactly what is was thinking
Yes, but in case of messaging we can't use GraphQL.
@@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.
GraphQL is synchronous. You’ll generally want service to communicate asynchronously to prevent things like rolling outages.
1.5x speed is the sweet spot
So slow it put me to sleep.
Yeah, a bit, but for non-native English speakers/listeners is good)
1.25x speed
@@gabcot03 I've used 1.75 XD
I barely understand english so Im fine with Evans' slowtalk 😅
i understand the speed was slow.. but the content is top notch isnt it ?
Everyone who speaks about microservices without mentioning their drawbacks deserves dislike automatically.