I also strongly endorse the Boundaries talk and am re-watching it now,
https://www.destroyallsoftware.com/talks/boundariesThe core concept of immutable values as the boundaries between components now seems self evident, but I can recall not appreciating this concept earlier in my career. Further, I don't think one can fully appreciate the importance of this concept until they've had to develop, maintain, and operate code both before and after this principle is applied. Here’s my story of being educated in the importance of “Boundaries”.
I started my career at a relatively small company that grew rather quickly. In developing more robust and reliable systems, I experienced the importance of this principle first hand. Commonly, a system that started as a small, low-value prototype could grow into a substantially large and important engineering system. Initial functionality may have been implemented in brittle, mutating code and these quickly became a pain point, particularly in testing.
I can recall several times where one seemingly innocent Java static method that mutated inputs or static fields was repeatedly the source of production errors. Adding test cases for these situations got increasingly complicated and time consuming with more and more mocks, stubs, and inspection of mutated state. Further, changing and adding functionality of the code itself became a tribulation of mentally working through the complexity of code and existing tests.
And what do you know, our recent changes reintroduced an old bug despite all of the tests passing. Turns out our existing tests to catch that bug only handled a specific manifestation of the fault, but didn't capture other cases. So of course, let us add some more test cases, each with their own menagerie of mocks, stubs, and inspection of mutated state.
Eventually, an experienced engineer would guide me to refactoring this functionality into isolated components. A single static method could be replaced by several Java classes; some classes to hold immutable state and others to perform state transformation. We may even introduce an interface so that different functionality could be provided through polymorphism. Tests became simpler and more robust such that fewer faults were discovered in production.
From the outside this may appear to be the classic Java Architecture Astronauts menace with a single static method replaced by a collection of classes and interfaces. We may have even had some XFactoryProvider interfaces. Yet the end result was easier to reason about and test, with the tangible benefit of fewer errors in production.
And I tell this story only so that I can say that I now appreciate this talk even more after living through the application of the “Boundaries” principle.