Successfully decomposing your monolith

Комментарий Программного комитета:

Основательный разбор практик перехода к микросервисной архитектуре.

Software design is hard, maybe the hardest part of building software systems... When designing distributed systems things get even more challenging. Now that microservices are so popular, we all want to decompose our monoliths to smaller units of independent components. If we don't want to end up with a distributed monolith, we need to have a toolbox of design concepts so we can achieve well-defined boundaries between our components groups described as "services" and "service boundaries" in the service-oriented architecture or SOA paradigm.

The traditional way of designing systems based on a domain/data model with very complex relationships and dependencies may kind of work when building a monolith, but just breaks apart when you're building distributed systems.

One of the pillars of distributed system design is to solve the coupling problem. In order to achieve this, we need to rethink how we design our components and "services". We need to move from monolith thinking to distributed thinking, leaving the single relational data model to multiple vertical bounded contexts that together compose a "service" boundary.

In this talk, Sean will walk you through the process of designing a very simplistic and naive vertical slice, while introducing the concepts from domain-driven design (DDD) and SOA, to build a single vertical. From there you will be able to do your first steps to design a loosely coupled distributed system, and be on the way to find your "service" boundaries.