Implementing the planet's largest e-commerce site using service boundaries

How often did you see a session about any kind of services and heard about how important it was to find the right boundaries, but until now you wondered how to find the right boundaries. Or what those boundaries look like once implemented, how services behave and what data they own. And how on earth business data cannot cross those service boundaries, but invoices are required to have product, customer and pricing details.

In this session we'll see an example of how the planet's largest electronic retailer would find the service boundaries for its checkout process. Then we'll look at how each service is part of choreographing this complex business process in an actual implementation. You'll finally understand the full flow from finding service boundaries to implementation and be able to break down a big ball of mud into a maintainable and decoupled system.

Autonomous microservices don't share data. Period.

Are you building a monolith using microservices? If a small change in business logic or in data requires you to modify code in more than one service, you probably are. Isn't it unbelievable that even using the latest technologies like .NET Core, containers, serverless and more doesn't help? In this session we'll discuss why technology doesn't change coupling. We'll have a different look at microservices. One where they'll truly be autonomous and not share data at all.

Unique session of 350 slides that I go through in 40 minutes and then possibly present demos. It was build using the Lessig Method Presentation Style. It teaches a different style of modeling your architecture.

Dealing with eventual consistency

As software architects we want to make our systems more performant, maintainable, understandable, or any other thing-able. We use infrastructure like Azure Service Bus or Service Fabric. Maybe we’ll introduce patterns like CQRS and Event Sourcing. Many of these choices introduce eventual consistency, but users expect immediate consistency. They don’t want to wait for eventually. They expect feedback now. There are, however, ways to work around this.

So what exactly is eventual consistency and how can we make it work? In this session, we’ll have a look at different patterns, both in the user interface and the back end, that give our users immediate feedback even though the back-end system is not. We’ll discuss how to solve the complexity of dealing with eventual consistency, without sacrificing decomposability or performance.

Change your architecture during deployment

Many systems start with diagrams of boxes and arrows and the promise of high consistency and low coupling. The boxes are supposed to be loosely coupled components, but each arrow often results in a highly coupled dependency at runtime. What if we can do something about it… during deployment?

In this webinar, we’ll identify design decisions that influence your system’s behavior both at design-time and run-time. We’ll observe how changing your design during deployment gives you many opportunities for making trade-offs to improve function and performance and gives you the information you need to shape your system architecture.

Event Driven microservices in vertical slices

Did you build your system using microservices but ended up with a distributed monolith?

In this workshop, we'll go beyond the hype and build a solid foundation of theory and practice on architectural styles like:

- Vertical Slices Architecture
- Event Driven Architecture
- Microservices Architecture
- Service Oriented Architecture

Without making your system even more complex and unmaintainable, actually look at how we can solve those problems, covering topics like:

- Data ownership across the enterprise
- Fault tolerance of our processes, transactions, and data
- Scalable event-processing endpoints
- Long-running multi-stage business processes and policies

You’ll better understand architectural concepts and DDD concepts such as bounded contexts and data ownership.

We’ll apply those concepts to build a simple, yet fully functional, order management system sample with a microservices architecture, using patterns such as command processing, pub/sub, and long-running sagas.

Some reviews when I gave this workshop before:

- A dedicated trainer, able to explain architecture topics at the level of the listeners. Each time he explained it from a development perspective with code and correlating it with diragrams for the architectural perspective.
- Amazing job, thanks for taking the time to explain these topics to us. Can't wait to apply this knowledge.
- Fun trainer, has a lot of knowledge and lots of experience. It shows.
- Information was interesting and presented clearly. Trainer's enthusiasm and passion was clearly visible.