Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The CxO guide to microservices

Jim Highsmith, Executive Consultant; Neal Ford, Director, Software Architect, and Meme Wrangle, ThoughtWorks | Jan. 27, 2017
Experts from ThoughtWorks share why senior executives should pay attention to microservices.

However, other bounded contexts (like Orders) cannot see those implementation details. While the domains may send messages to each other for coordination purposes, neither domain can pierce the bounded context of another. Thus, developers in one bounded context freely make implementation changes without worrying about breaking other domains.

The container in microservices is the physical manifestation of bounded context in Domain-Driven Design (DDD): each represents an encapsulation barrier to prevent implementation details from interfering with other parts of the system. The isolation provided by the bounded context presents a different way to structure software architecture.

In the past, designing architecture primarily revolved around technical architecture: architecture structural patterns, libraries, frameworks, and so on. For example, the layered architecture is quite common in many organisations:


Figure 1: Traditional layered architecture. Click on image to enlarge.

In Figure 1, the architect split along technical layers, making it easy to swap out an entire layer if needed. For example, if developers needed to change the persistence mechanism, all the relevant code appears in the persistence layer.

How often do developers swap out the entire persistence layer? Virtually never. How often do your teams work on concepts like Customer? Every day!

Where does Customer live in the layered architecture, represented by the peach-colored images in Figure 1? Partially in the presentation layer, the business layer, persistence, and so on. Thus, the common unit of change on projects-to the domains-is poorly supported in the layered architecture because common change affects each layer.

The impact is more severe if different layers represent different parts of the development workforce. For example, a change to Customer will likely entail changes to user interface, business logic, persistence, and other characteristics. If your organisation has developers, DBAs, user interface designers, and operations in separate HR silos, the coordination cost to make common changes is enormous.

Microservices, with its emphasis on decoupling and containerisation, flips the traditional picture in Figure 1, making the domain the primary architectural element, as shown in Figure 2.


Figure 2: Domain-centric architecture. Click on image to enlarge.

In Figure 2, the layered architecture still exists, but the coupling boundary is the domain, relegating the technical architecture to an implementation detail, now encapsulated within the domain. Building a domain-centric architecture with workers isolated from one another in technology-centered silos is difficult.

One of the significant problems that many technologists building a digital enterprise have is being weighed down by legacy systems that need to be untangled in order to support new initiatives such as mobile applications. Increasingly, these enterprises are using microservices as a key strategy in this untangling process.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.