1:04 Intro. 1:45 Why do I like Microservices? 7:57 Services and Messages 9:22 Bounded Context 10:36 Context Map Explanation 17:35 Models need to be clear not big 22:44 Not all of a large system will be well designed (Say it three times in the mirror every morning! 😄)
25:43 Interchange Context 29:19 Why not logical boundaries? 32:56 Wrap up 36:26 One more time: "Not all of a large system will be well designed" 37:22 Some time for questions
I love how eric doesn't have to be this eccentric other worldly person that we can barely make sense of. Hes one of these architects that leaves the jargon behind and speaks to us as normal people. Great speech !
I started watching this at 1.5, came back to it a few hours later, forgetting I had sped it up, and it took me about 3 minutes to realize that it was being sped up. haha Thanks for the tip.
This was actually the perfect speed for me, gave me time to go back in my mind and draw similarities from my experience to what Eric was referring to. That really enhanced the experience. This is more of a philosophical discussion requiring lot of introspection rather than a "how-to".
I like how Eric outlines the problem of multi-team software development in the first 25 minutes. Chances are you've seen this happen but weren't conscious of the patterns.
i have been relistening to this talk year after year and every year i am able to find something very useful applicable to the different things i have done over the years. truly a gem of a talk.
Hey Evans - what is your reaction to this th-cam.com/video/TX2lF5doZP0/w-d-xo.html - if we apply your DDD strategies with model execution will that not be very much faster than what you suggest?
1:04 Intro. 1:45 Why do I like Microservices? 7:57 Services and Messages 9:22 Bounded Context 10:36 Context Map Explanation 17:35 Models need to be clear not big 22:44 Not all of a large system will be well designed (Say it three times in the mirror every morning! 😄) 25:43 Interchange Context 29:19 Why not logical boundaries? 32:56 Wrap up 36:26 One more time: "Not all of a large system will be well designed" 37:22 Some time for questions
I always thought of this that a service owns its repository (DB), but what if I have a legacy monolithic system with a big DB, and instead of having one service that does everything why can't we have different micro services that deal with the same DB?
It depends on the database system. Conflicts with the data updating, how it is used, having "multiple sources of truth" determining what is correct data; this can get complicated. It is technically do-able, but it is usually beneficial to wrap the raw data functionality in some logic to control and verify and prevent whatever problems might otherwise crop up.
All of digital electronics has an anti corruption layer at each logic gate, each transistor: they interpret and clean up a noisy continuous signal to a 0 or 1. Cannot interpret data more simply than in two ways.
1:04 Intro.
1:45 Why do I like Microservices?
7:57 Services and Messages
9:22 Bounded Context
10:36 Context Map Explanation
17:35 Models need to be clear not big
22:44 Not all of a large system will be well designed (Say it three times in the mirror every morning! 😄)
25:43 Interchange Context
29:19 Why not logical boundaries?
32:56 Wrap up
36:26 One more time: "Not all of a large system will be well designed"
37:22 Some time for questions
I love how eric doesn't have to be this eccentric other worldly person that we can barely make sense of. Hes one of these architects that leaves the jargon behind and speaks to us as normal people. Great speech !
yeah I guess "F needs to conform to A" is very human language, lets pretend context map is our everyday language!
good talk! very usefull.
but i recomend to switch the speed of video to 1.5 - Eric is very slow speaker as for me (not native english speaker i mean)
Great talk, indeed!
+Ali Horezmi Thanks for the advice. 1.5 felt very natural, indeed!
Irony is so underestimated. :D
I started watching this at 1.5, came back to it a few hours later, forgetting I had sped it up, and it took me about 3 minutes to realize that it was being sped up. haha Thanks for the tip.
This was actually the perfect speed for me, gave me time to go back in my mind and draw similarities from my experience to what Eric was referring to. That really enhanced the experience. This is more of a philosophical discussion requiring lot of introspection rather than a "how-to".
Kerim Berdimyradov How do you adjust speed (iPad)? I just see quality.
I highly recommend watching this in 1.5x speed. It sound surprisingly normal and your done quicker.
8:20 how do Services understamd Messages?
7:57 wpwhats a Service?
9:20 understamding Messages requires a context
Dang I'm listening on 1.25x and not noticing a difference lol I kinda appreciate that though
Does anyone understand the difference between the generic language of the Interchange Context and the Published Language? Are the in essence the same?
Speed up the video to 1.25x ! It will be best
I like how Eric outlines the problem of multi-team software development in the first 25 minutes. Chances are you've seen this happen but weren't conscious of the patterns.
i have been relistening to this talk year after year and every year i am able to find something very useful applicable to the different things i have done over the years. truly a gem of a talk.
I just love listening how Eric explains.
x1.25 works best ;)
Lol, I tried and it is true
Awesome talk. Very helpful !!
I like the analogy about Car engine and Very big ACL for engine. Great imagination.
Brilliant mind comes through shining in this very helpful presentation. Thanks Eric!
Great mind in the body of the actor from Sledge Hammer. Good stuff!
2x. I was looking for 3x
Hey Evans - what is your reaction to this th-cam.com/video/TX2lF5doZP0/w-d-xo.html - if we apply your DDD strategies with model execution will that not be very much faster than what you suggest?
1:04 Intro.
1:45 Why do I like Microservices?
7:57 Services and Messages
9:22 Bounded Context
10:36 Context Map Explanation
17:35 Models need to be clear not big
22:44 Not all of a large system will be well designed (Say it three times in the mirror every morning! 😄)
25:43 Interchange Context
29:19 Why not logical boundaries?
32:56 Wrap up
36:26 One more time: "Not all of a large system will be well designed"
37:22 Some time for questions
"Sometimes you know that you need a wall ...", that's absolutely right!!!
I always thought of this that a service owns its repository (DB), but what if I have a legacy monolithic system with a big DB, and instead of having one service that does everything why can't we have different micro services that deal with the same DB?
It depends on the database system. Conflicts with the data updating, how it is used, having "multiple sources of truth" determining what is correct data; this can get complicated. It is technically do-able, but it is usually beneficial to wrap the raw data functionality in some logic to control and verify and prevent whatever problems might otherwise crop up.
Because if you have a single monolithic db performance will suck, bcoz it will be a bottleneck. The bottleneck is usually io operations
keep the old system, and keep building new microservices with their own datastores, slowly making the old absolute
All of digital electronics has an anti corruption layer at each logic gate, each transistor: they interpret and clean up a noisy continuous signal to a 0 or 1. Cannot interpret data more simply than in two ways.
Aside from AC which D used to conform A, to accommodate A's change. it could also be a chance to evolve our Domain Model when change comes.
AC = write validations !
very enlightening
안녕하세여
Always be in the domain of what you develop. Don't develop a washingmaschine while being in the domain of lawnmowers. Pretty Obvious right?
This talk is a waste of time. Sadly, Eric, is a very mediocre speaker. The whole talk can summerized in 3 sentenses.
why why why.???????