No video :(

DDD and Microservices: At Last, Some Boundaries!

Подписаться 231 тыс.

Просмотров 66 тыс.

50% 1

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.

Опубликовано:

28 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 29

@zhou7yuan 3 года назад

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 3 года назад

thank you

@Hangar1318 2 года назад

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 4 года назад

Settings -> Reproduction Speed -> 1,5X

@kodermail 3 года назад

shift+>, shift+> )

@patricknazar 4 года назад

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

@tkousek1 6 лет назад

Thank you for this great presentation

@prabhusingh7481 6 лет назад

Nice presentation

@nexus888 2 года назад

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.

@thatpaulschofield 2 года назад

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.

@pbdrus 6 лет назад

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 2 года назад

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.

@amotorcyclerider3230 4 года назад

So slow it put me to sleep.

@inc.1424 4 года назад

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

@gabcot03 4 года назад

1.25x speed

@imienazwisko486 4 года назад

@@gabcot03 I've used 1.75 XD

@chapultepec 4 года назад

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

@sohamjoshi9527 2 года назад

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

@chris.dillon 7 лет назад

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 6 лет назад

exactly what is was thinking

@MaTeGames 5 лет назад

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

@bartvanderwal6730 5 лет назад

@@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.