System Architecture: Bounded Contexts

Originally posted on Dec 2, 2016 at https://www.pluralsight.com/tech-blog/system-architecture-bounded-contexts


Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size.

In order to maximize throughput, how big should a team be? One pair of developers? Ten pairs of developers? For the time being, we have settled on two to three pairs of developers with a Product Manager, a UX Specialist and a DevOps Engineer. Given this team structure, we ask ourselves how big of a chunk of our system can that group truly own?

We expect a team to own the discovery, design, development, delivery, and production support of their part of the overall system. This means that we have to divide the system carefully. If the creation of a new feature requires coordination across multiple teams, there will be ongoing questions about who should get alerted when there is an issue at 3:00 am. We like to avoid those alerts, but more importantly, we want to answer the question of who to alert ahead of time.

At Pluralsight, a Bounded Context is a part of the overall system that can be owned entirely by one team. A Bounded Context has clear boundaries. As it is supported by a Product Team, it might be considered a separate product in it's own right.

Technical Characteristics of Bounded Contexts


Exclusive access to its data store(s)

This means that no other team or service or Bounded Context may access the database(s) used by this Context. This encapsulation of data allows the team to evolve their schemas more easily as they don't have to coordinate with other teams. This also allows the team to change data storage technology entirely. You can move from flat files to Postgres to Redis to Cassandra and back again as the needs of the customer change.

Independent Build Pipeline

Teams may use the shared build and deploy servers but they have an independent build for their Bounded Context. Bounded Contexts also provision exclusive (virtual) hardware at our hosting company. This allows them to validate and deploy their components of the system on their own cadence without interfering with or putting at risk other parts of the overall system.

Deployable Units

A Bounded Context consists of one or more components such as websites, HTTP APIs, Windows Services/Daemons, apps, etc. All of these components are built to support the overall purpose of the Bounded Context and the team is responsible for the interactions between them.

Unified Domain Model

The team can create a model of the domain within the Bounded Context that includes all the rules of this part of the system with no concern regarding the rest of the system. This allows for highly tuned and expressive models which can improve communication and productivity.

Communication Patterns


Bounded Contexts are part of a larger system. We do not prescribe the architecture nor communication patterns within the Bounded Context. Instead we choose to trust that the team of professionals which owns the Context will make good choices. We do have some simple rules for communication between the Bounded Contexts.

Favor Asynchronous Communication

We temporally decouple the contexts from each other whenever possible. This is accomplished by passing JSON-formatted messages representing Business Events through a publish/subscribe message broker. This allows each Bounded Context to produce these Events at whatever rate is appropriate without worrying about the availability of consumers. Queuing allows each subscribing system to level off the load of incoming messages and scale consumers to meet that load. Teams cache the Business Events that they need in their own data stores so that they can execute business logic quickly without depending on external (to their Bounded Context) resources.

System APIs

Some operations are a poor fit for an asynchronous approach. Specifically, these are operations that are highly algorithmic or rely on highly stateful data. Examples include calculation of search results (imagine caching the results for all possible searches), calculation of the next question in a dynamic assessment engine, allocation of a limited resource such as a limited number of beta tester seats. For these cases, Bounded Contexts expose HTTP+JSON APIs that can be consumed by other Bounded Contexts within the system.

Delivery, Autonomy, Responsibility, Innovation


By building our system as a collection of Bounded Contexts, we have set each team up to succeed at delivering a quality product to our customers. Most of our teams are fully responsible for a small number of Bounded Contexts. This ownership allows our engineers to embrace responsibility which, in turn, encourages our leadership to trust our engineers with greater autonomy. Greater autonomy leads to greater innovation within Bounded Contexts as we try to regularly delight our customers.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more