“the code that changes together, stays together.”

By reducing the number of assumptions that one module (or microservice) makes about another, we directly impact the connections between them. By keeping the number of assumptions small, it is easier to ensure that we can change one module without impacting others. If a developer changing a module has a clear understanding as to how the module is used by others, it will be easier for them to make changes safely in such a way that upstream callers won’t also have to change. With microservices, this applies as well, except that we also have the opportunity to deploy that changed microservice without having to deploy anything else, arguably amplifying the three desireable characteristics that Parnas describes of improved development time, comprehensability and flexibility.

The connections between modules are the assumptions which the modules make about each other.

The reality as Parnas explored through much of his work, is that having modules doesn’t result in you actually achieving these outcomes. A lot depends on how the module boundaries are formed. From his own research information hiding was a key technique to help get the most out of our modular architectures

Flexibility Modules can be changed independently from one another, allowing for changes to be made to the functionality of the system without requiring other modules to change. In addition, modules can be combined in different ways to deliver new functionality.

Comprehensability Each module can be looked at in isolation, and understood in isolation. This in turn makes it easier to understand what the system as a whole does.

Improved Development Time By allowing modules to be developed independently, we can allow for more work to be done in parallel, and reduce the impact of adding more developers to a project.

a concept developed by David Parnas to look at the most effective way to define module boundaries. Information hiding describes a desire to hide as many details as possible behind a module (or in our case microservice) boundary. Parnas looked at the benefits that modules should theoretically give us1, namely:

which are vital to grasp when it comes to working out what makes for a good microservice boundary - information hiding, cohesion, and coupling.

three key concepts

The company has a website, but feels that now is the time to double-down on the online world.

MusicCorp was recently a brick-and-mortar retailer

Information Hiding

Cohesion

Coupling

The Interplay of Coupling And Cohesion

Domain Coupling

Pass Through Coupling

Common Coupling

Content Coupling

Volatility

Data

Organizational

Layering Inside Vs Layering Outside

Mixing Models And Exceptions

Ubiquitous Language

Aggregate

Bounded Context

Hidden Models

Mapping Aggregates and Bounded Contexts to Microservices

Turtles All the Way Down

The Dangers Of Premature Decomposition

Communication in Terms of Business Concepts

Logistics

The Process

Summary

Event-storming

Just Enough Domain-Driven Design

Different Goals, Different Drivers

Alternatives to Domain-Oriented Decomposition

Types Of Coupling

What Makes a Good Microservice Boundary?

Introducing MusicCorp

Chapter 2. How to Model Microservices

a microservice architecture is one that can give you a lot of flexibility as you continue to evolve your system. That flexibility has a cost, of course, but if you want to keep your options open regarding changes you might want to make in the future, it could be a price worth paying

Software as a Service (SaaS) applications are, in general, also a good fit for a microservice architecture. These products are typically expected to operate 24-7, which creates challenges when it comes to rolling out changes. The independent releasability of microservice architectures is a huge boon in this area.

the single biggest reason that I see organizations adopt microservices is to allow for more developers to work on the same system without getting in each other’s way. Get your architecture and organizational boundaries right, and you allow more people to work independently from one anothers, reducing delivery contention.

If you are running the software yourselves, you are able to offset this new complexity by adopting new technology, developing new skills, and changing working practices. This isn’t something you can expect your customers to do. If they are used to receiving your software as a Windows installer, it’s going to come as an awful shock to them when you send out the next version of your software and say, “Just put these 20 pods on your Kubernetes cluster!”

It’s much easier to move to microservices later, after you understand where the constraints are in your architecture and what your pain points are—then you can focus your energy on using microservices in the most sensible places.

For a small team, a microservice architecture can be difficult to justify because there is work required just to handle the deployment and management of the microservices themselves. Some people have described this as the “microservice tax.” When that investment benefits lots of people, it’s easier to justify.

When working with smaller teams with just a handful of developers I’m always very hesitant in suggesting microservices

Uber initially focused on limos, and Flickr spun out of attempts to create a multiplayer online game. The process of finding product market fit means that you might end up with a very different product at the end than the one you thought you’d build when you started.