Why do authors write technical books about topics like software architecture? They write them when then have figured something out, a “best practice” that is general enough and has matured enough to tell the rest of the world. In fact, architects rely on the current (but always shifting) notion of “best practices” for guidance in solving tough problems.
But what happens where there are no best practices? What if no one has ever solved this particular problem before? What if there are no good answers, just varying degrees of awfulness?
When you’re a software developer, you build outstanding skills in searching online for solutions to your current problem. For example, if you need to figure out how to configure a particular tool in your environment, expert use of Google finds the answer.
But that’s not true for architects. For architects, many problems present unique challenges because they conflate the exact environment and circumstances of your organization–what are the chances that someone has encountered exactly this scenario and blogged it or posted it on Stack Overflow?
When architects encounter novel problems (by the way, they’re all novel when you become an architect), how do they make decisions if no “best practices” exist and no one has ever solved this problem before?
The real job of an architect is, when presented with a novel situation, how well can they delineate and understand the tradeoffs on either side of the decision, so that the organization can make the best informed decision.
This session consists of lecture mixed with group-based hands-on exercises. Attendees won't need technology beyond the ability to reference web sites. The exercises illustrate the tradeoffs illustrated in the lecture, where groups design architectures to solve particular problems.
Target Audience
The target audience is existing architects, aspiring architects interesting in learning about fundamental tradeoffs, and developers working within complex architectures.
No laptop is required, but access to a browser on some device is necessary as the exercises are online.
Outline & Agenda
Architectural Modularity
- Defining modularity and why it’s important
- Business and technical drivers
- Hands-on exercises: Modularity drivers
Service Granularity
- Grains of sand anti-pattern
- Granularity disintegration drivers
- Granularity integration drivers
- Analyzing tradeoffs
- Hands-on exercises: Determining service granularity
The Structure of Distributed Systems
- Concepts: Architectural quantum and its importance
- Architecture quantum examples
- Hands-on exercises: Identifying architectural quanta
Data Topologies for Distributed Systems
- Monolithic data topology
- Domain data topology
- Database-per-service topology
- Data topology tradeoffs
- Aligning data topologies with distributed architectures
- Creating data domains
- Resolving data dependencies
- Hands-on exercises: Choosing the right data topology
Data Ownership and Access
- Creating bounded contexts: Service granularity revisited
- Managing common data ownership
- Managing joint data ownership
- Remote data access patterns
- Data topology coupling revisited
- Hands-on exercises: Accessing remote data
Contract and Payload Patterns
- Data-based payloads
- Key-based payloads
- Data payload tradeoff analysis
- Anemic events
Event-Driven Architecture Patterns
- Event-driven architecture review
- Derived event granularity
- Swarm of gnats event anti-pattern
- Hands-on exercises: Identifying derived events
- Extensible event pattern
- Event forwarding pattern
Communication Protocols
- Synchronous communication
- Asynchronous communication
- Dynamic quantum entanglement
- Hands-on exercises: Asynchronous communication
Managing Workflows
- Orchestration workflows and tradeoffs
- Choreography workflows and tradeoffs
- Front controller hybrid pattern
- Combining workflow topologies
- Managing workflow state
Distributed Transactions
- ACID (database) transactions
- BASE (distributed) transactions
- Compensating updates
- Managing transactions through state machines
- Hands-on exercises: Creating a workflow saga
Transactional Sagas
- Transactional sagas explained
- Epic Saga
- Fantasy Fiction Saga
- Fairy Tale Saga
- Parallel Saga
- Phone Tag Saga
- Horror Story Saga
- Time Travel Saga
- Anthology Saga
- Transactional sagas as a tool
What participants say about this workshop
"The workshop helped me support my architectural decisions with evidence, rather than just gut feeling."
- workshop participant 2023
"The topic was highly relevant and the pragmatic approach, combined with practical exercises, made the theory come alive. I wish we had another half-day to delve even deeper into discussing the pros and cons. This workshop has had a huge impact; it has given me a clear language to articulate what I’m doing in my daily work."
- Emil Holmegaard, Management Consultant, 7N - workshop participant 2024
"I liked the practical approach of the instructors. There was a good mix between presenting the theory and making the excercises. This workshop has provided me insights on how others might think."
- Arjan Smit, Technical Software Engineer, Alten - workshop participant 2024
