content_image/1012455.jpg
Within those tiers, a well-designed application is broken down internally into separate components that are responsible for each of the application’s functions. However, they still all run in the same application server runtime. 

Software development and architecture approaches like 12-factor and microservices started to advocate for those components to become truly independent. Ideally, they would be completely decoupled from each other down to the network level. This is shown in Figure 4-10. 

<img src='content_image/1012455.jpg'>

With these changes in application architectures, an issue started to surface: how to define an application boundary. 

For monolithic applications the logical boundary of the application corresponded with the physical implementation of the application itself. After the application components become truly decoupled and independently deployed, the boundary is no longer implicitly present. 

Therefore, if a boundary must exist to group all the application components in a single logical construct, that boundary must be explicitly identified and designed in. 

## 4.7.2 Why do application boundaries matter? 

It might be tempting to think that we could dispense with application boundaries altogether and simply manage business functions granularly. However, anyone with experience of even a moderately sized IT landscape recognizes that clear ownership is required at a much more 

