Clean Architecture - What is the Humble Object Pattern?

Architecture Layers

The discussion on architecture layers in Clean Architecture highlights the importance of abstraction layers in maintaining clear boundaries and decoupling code. Alan Underwood explains that these layers, such as the database, application, and interface layers, act as boundaries that different parts of the system must adhere to 1. Joe Zack adds that having a database gateway layer above the ORM prevents implementation details from leaking into the application, allowing for easier swapping of components 1.

You could swap it out with a version that reads off of a file, you could swap it out with an input hibernate version or a Java hibernate version or entity framework, whatever. That's where the benefit of having that layer of abstraction between the use case and the ORM buys you.

--- Joe Zack

This layered approach ensures that changes in one layer do not affect others, promoting a more modular and maintainable codebase 2.

   

Humble Objects

The Humble Object Pattern is crucial for increasing testability at boundaries in Clean Architecture. Joe Zack clarifies that humble objects are those that are hard to test, which might seem counterintuitive at first 3. Alan Underwood explains that the view should only present data without any logic, making it a humble object but also the hardest to test due to its potential for frequent changes 3.

The view is doing nothing other than presenting data. Now, I ask you this because we're all aware of templates, right? So does this mean that you cannot have any conditionals in your templates for your view presentation?

--- Joe Zack

Joe further elaborates that using humble objects at boundaries, like service listeners, can significantly enhance testability by isolating the parts of the system that are difficult to test 4.

   

Boundary Decisions

Deferring boundary decisions is a key strategy in Clean Architecture to maintain flexibility and manage dependencies effectively. Joe Zack emphasizes that deferring these decisions helps avoid tightly coupling components, which can make future changes more difficult 5. Alan Underwood adds that maintaining partial boundaries can help manage complexity without generating excessive code 6.

It's easy to cheat the boundary. And so it's easy for things to get dirty and then it gets hard to split them up later.

--- Joe Zack

Joe also discusses the concept of having interfaces at each boundary to ensure that different parts of the system can communicate without being tightly coupled, thus promoting a more modular architecture 7.