Lesson 165 - Event-Driven Architecture

Рет қаралды 7,877

Күн бұрын

Even though event-driven architecture has been around for a very long time, it continues to gain in popularity, particulary as systems become less deterministic and require faster processing and better scalability. In this lesson I’ll describe how the event-driven architecture style works, talk about its strengths and weaknesses, and explain when you should use it and when you should avoid using it.
Reference Links:
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2

Пікірлер: 31

@yellowsubmarine7059 Жыл бұрын

I love your videos and your books. Absolutely a reference for any software architect. Thank you very much for sharing your knowledge.

@markrichards5014 Жыл бұрын

Thanks!

@jffrysith4365 4 ай бұрын

these videos are absolutely amazing. The diagrams are so good, and so well explained that I can so easily follow what they are and why we want them. I also love that you express your opinions (as anyone does) but you also actually explain what's happening. (In class they define things purely on the opinions. to the point where they defined SOA as cheap and good...)

@markrichards5014 4 ай бұрын

Thanks for the encouraging words!

@gabrielg9592 Жыл бұрын

Thank you so much for these videos! As soon as I get the notification that you've uploaded a new video, I go watch it straight away. I can say I've learnt a lot from you! I wanted to ask you a slight off-topic question, as a Software Architect, what's your opinion (if any) on DDD?

@markrichards5014 Жыл бұрын

Thanks! I think DDD is extremely useful to help understand the business domain. Once of the challenges I still see with teams is translating DDD into the physical structures of our systems. I suppose that would make a great video, huh?

@gabrielg9592 Жыл бұрын

@@markrichards5014 Well I for one would absolutely love if you made a video about that! Thanks for the reply

@zshn Жыл бұрын

This series is my favorite. Thank you. Will you creating a separate playlist for it?

@markrichards5014 Жыл бұрын

The playlist is already out there - it's called "Software Architecture Monday" and includes all of my videos.

@krishanumajumder5314 Жыл бұрын

Very helpful! Thank you so much!

@markrichards5014 Жыл бұрын

Glad you enjoyed it

@vickeey88 4 ай бұрын

Thank you for all the videos. Really loved it and never missed it. Do you have any suggestions when your event schema undergoes changes continuously? especially when breaking changes are introduced. Which requires updating and coordinating deployment across dependencies.

@markrichards5014 3 ай бұрын

I feel your pain - contracts in EDA are difficult to change because you are never sure who is processing the event. One technique is to minimize the contract data and have services get the rest of the data in the database, but this just moves the contract to the schema. So, it depends on why the contract is changing so much and what sort of data is changing. Changing over to a strict contract using a schema allows you to version, making it a bit easier to adopt changes at a slower pace. Sorry I can't be of more help on this very hard problem!

@vickeey88 2 ай бұрын

@@markrichards5014 thanks for answering. indeed a difficult problem. As you pointed out, we are using versioning but adapting changes on consumer takes more time. We are using Message Envelope pattern, where the version is sent in header part of the message. The consumer will need to implement a parser for specific version. Not a ideal solution but works for us :)

@aleksandr2245 Жыл бұрын

Was on your oreilly live events with Neal Ford and loved it a lot:) Maybe you are planning a video about transaction handling in EE architecture? Thank you!

@markrichards5014 Жыл бұрын

That's part of our Architecture: The Hard Parts workshop we do at conferences - it's much too big a topic for a 10 minute video! But great idea though...

@luramarchanjo9408 Жыл бұрын

Very nice, thank you soo much

@markrichards5014 Жыл бұрын

👍

@vitorgilpinheiro 11 ай бұрын

In some of your videos like this one I am missing the role of the database. In some architecture types the database is the bad guy (for performance) and putting a queue in between to allow for asynchronous database transaction makes the architecture great in terms of performance and elasticity (space-based architecture for example). My point is: I can imagine that if these event processors share the same database, or even if they have separate databases but have to do complex interactions with them, then the whole thing will still be slow. Thanks for your content.

@markrichards5014 11 ай бұрын

You are right - I should do some separate videos on the role of the database and database topologies in each of these architecture styles - thanks for the idea! In EDA, the tradeoff is performance vs. coupling; if I need data in EDA, I can get it from the database (which is coupling itself but fast), or I can ask another event processor for the data if using bounded contexts (which is coupling also but slower and has a service dependency).

@code4it 5 ай бұрын

Going back to the "purchase book" example. Say that PaymentService emits an event (PS1) and OrderFulfillmentService emits another event (OFS1), and both events are related to a specific book. The WarehouseService must work only after it has received both PS1 and OFS1 for the same book. How would you implement this situation?

@markrichards5014 5 ай бұрын

Event timing and aggregation is hard; one solution is using an event an aggregator that waits for both events and publishes a new one.

@sant4398 Жыл бұрын

Thanks for one more lesson! Seems for me the event driven architecture is something can't exists as a standalone, not being part of some (micro)service-based-oriented architecture?

@markrichards5014 Жыл бұрын

EDA can be applied in a pure form without needing microservices or other architecture styles. That said, many times not every part of the system is suited for EDA, hence the use of hybrids.

@zshn Жыл бұрын

What does each star mean? What does the arch need to be/do to earn a star in each category?

@markrichards5014 Жыл бұрын

The stars indicate what level the characteristic is supported; 1 star means the characteristic (e.g., scalability) isn't well supported, whereas 5 stars means its extremely well supported.

@zshn Жыл бұрын

@@markrichards5014 yes but how do you quantify a star in each category.