LDNUG March 2019
***IMPORTANT*** You must sign up via the Skills Matter website to get a door entry code https://skillsmatter.com/meetups/12199-london-dot-net-march-2019
18:30 – 19:30: Dylan Beattie: “Architecture: The Stuff That’s Hard to Change”
19:30 – 20:30 Ian Cooper: “Event Driven Collaboration”
Dylan Beattie: Architecture: The Stuff That’s Hard To Change
We’ve all heard of the idea of ‘software architecture’. We’ve read books about domain-driven design and event sourcing, we’ve been to conferences and learned about micro services and REST APIs. Some of us remember working with n-tiers and stored procedures… some of us are still using them. But the role of a systems architect is still one of the most misunderstood things about the software development process. What does the architect actually do? If you’re working with a systems architect, what can you expect from them? And if you are a systems architect, what are your team expecting from you? In this talk, Dylan will share his own insights into the idea of architecture as part of a software development process. We’ll explore some popular architectural patterns and processes — and a couple of obscure ones as well — and look at how, and when, you can incorporate those patterns into your own projects. We’ll talk about how the idea of software architecture has changed over time, and share some tips and advice for developers who find themselves working with architecture as part of their role.
Ian Cooper: Event Driven Collaboration
When we move from a monolith to microservices we abandon integrating via a shared database, as each service must own its own data to allow them it to be autonomous. But now we have a new problem, our data is distributed. What happens if I need one service needs to talk to another about a shared concept such as a product, a hotel room, or an order? Does every service need to have a list of all our users? Who knows what users have permissions to the entities within the micro service? What happens if my REST endpoint needs to include data from a graph that includes other services to make it responsive? And I am not breaking the boundary of my service when all of this data leaves my service boundary in response to a request?
Naive request-based solutions result in chatty calls as each service engages with multiple other services to fulfil a request, or in large message payloads as services add all the data required to process a message to each message. Neither scale well.
In 2005, Pat Helland wrote a paper ‘Data on the Inside vs. Data on the Outside’ which answers the question by distinguishing between data a service owns and reference data that it can use. Martin Fowler named the resulting architectural style; Event Driven Collaboration. This style is significant because it shifts the pattern from request to receiver-driven flow control.
PLEASE REMEMBER TO SIGN UP HERE: https://skillsmatter.com/meetups/12199-london-dot-net-march-2019