When designing the architecture for an application or system of interrelated applications, it is essential to identify which quality attributes of the system are most important to the users, developers, and owners. Often this is done implicitly based on the experience and preferences of the various people participating in the project. When quality attributes are selected with intention and purpose, they help guide the design of the system. At Pluralsight, the quality attributes we focus on have evolved as the company has evolved.

In order for a technology organization to deliver products in support of a company's mission, decisions about which technology to use and how to use it must be made regularly. Creating a strategy for making these decisions is a problem for many organizations.

APIs are an integral part of our distributed system here at Pluralsight. We use them to communicate between and within bounded contexts. One of our engineering team mottoes is "Be Explicit." To that end, we have a categorization system for the APIs we build and publish. This helps us know what the API is for and who should (and who shouldn't) be using it.

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 their creator. 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. I have 4 broad categories of tests that I keep in mind to help focus my testing.

When we started on our journey towards bounded contexts, we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them.

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...