I have been doing a lot of software design work in past months. As you know design is not easy. It’s almost always about making (hard) decisions. It’s about considering alternatives and weighting options. In that sense, I’ve also tried to learn more and expand my knowledge about software architecture and software design. As the main source of usable knowledge, I find the “Domain-driven design” book. You’ve probably heard of the Repositories, Aggregates, Value object etc. But, what I value the most in this book is the part called “Strategic design”. It’s the part that talks about Bounded Contexts, Context Maps, Core domain etc. Really, this is the most valuable part of the book. Eric Evans, himself, in his What I’ve learned about DDD since the book talk kind of admits that putting that part at the end of the book was a mistake. If you do software architecture and design I strongly advise you to explore that part of the book. However there is one advice-practice, that changed the my thinking from ground up. I have read this article by Kevlin Henney. The title of the article is “Simplicity Before Generality, Use Before Reuse”. The article is about how to value concrete and specific solutions over the more general solutions. Business people mostly have problems that are specific to them and thus need specific solutions. Software people, on the other hand, like to generalize. They (we) like to see abstractions everywhere and try to come up with general solutions that can solve all the problems. Of course, this will not happen. This usually end by making things more complex without any benefit. Go and read this article.
