Chapter 11. Epilogue
This chapter covers
- Pointers to further reading material about architectural patterns
- Suggestions for improving your testing strategy
- Some hints on domain-driven design and finding out more about it
This book aims to be a style guide. It provides basic rules for object design that will be reflected in the declarations of your classes and methods. For many of these rules, you could build a static analysis tool that emits warnings when you don’t follow the rules. Such a tool could, for instance, warn you about methods that make state changes and return something. Or about services with methods that change their behavior after construction time.
There are two comments to be made here. First, I think it’s important to follow the rules but also to allow yourself to bend them in some special cases, such as when quality doesn’t really matter, because you don’t have to maintain the code for a long time. Or when, in certain cases, it would take a lot of work to apply all the rules, and the benefits don’t outweigh the required effort. However, don’t be too quick to judge. I’d estimate that in 95% of real-world scenarios, there really isn’t a case for taking shortcuts.