Absolutely agree with 1 ("Maintain one source of truth"), not just in a service but in an architecture. I am dealing with a microservice architecture where deci

Absolutely agree with 1 ("Maintain one source of truth"), not just in a service but in an architecture. I am dealing with a microservice architecture where decisions have been made to store the same state across different services. Needless to say this is massively challenging to keep in sync and requires a ton of work keeping the production systems consistent. Not to mention the difficulty of setting up proper test environments where any given data store might be reset or refreshed at any given moment, causing all kinds of havoc and causing people to lose trust in the test environments. For number 2, (please repeat yourself), the truth is in the middle. Don't repeat yourself when the proper abstractions present themselves, and always be on the lookout for a good abstraction. But don't force an abstraction where it's not appropriate. Where to draw the line is the hard part and in my opinion comes from experience and intuition. If in doubt, repeat yourself. Number 3 (overused mocks) I find myself swimming against the tide of popular opinion. I think mocks are very valuable for unit testing. This doesn't mean you don't write your integration tests without the mocks, but I still think there's a ton of value in being able to quickly write a large number of fast unit tests that say "when this component does this, I expect the system under test to do that". As for leaking implementation details, I don't think it's such a big deal at the unit testing level. The details need to be tested somewhere. I appreciate this is an increasingly unpopular viewpoint but it has served me well. For number 4 (minimize mutable state) this is software engineering 101, but always bears repeating.