I’ve been unhappy with the async/background work model in my system for a while. The async logic always seems excessively complex, either entangled with business logic or creating opaque coupling between flows. However, my recent breakthrough on code structure suggested a clear path to adding background work in an aspect-oriented style. Let’s examine a refactor that helped me prove decorator-style async communication.
The Language of the System by Rick Hickey is an illuminating talk about why systems differ from programs. It provides a clear framework for understanding and addressing the differences. I believe these same ideas underpin some of the recent movements in software design philosophy. Let’s explore.
A general design for integrating notifications (email, text, push, etc) has long eluded me. However, a recent refactor using the concepts of Synthesizing Project Organization Methods has settled my search. Here I’ll explore my refactoring experience and why the conceptual shift is generically more stable.
C# (and Java) offer a type call enum (aka enumeration). It represents a fixed list of possible values and is a powerful tool for communicating intentions through the type system. However, a recent legacy project forced me to face the shortcomings of enums and realize an even more powerful pattern, struct named constants.
I got to thinking about the Rediscovering Options post. The volatility analysis portion is an important artifact of my design process. The current version requires reading the whole list to comprehend the results. How could I make it better?
Configuration is a powerful tool and a dangerous temptation. My goal in this post is to walk through the ways I mishandled configuration, ended up rediscovering the Options configuration pattern, and finally dive into specific design scenarios to show why Options is the most stable solution.
Part 2 of Righting software presents the most complete theory of project management I’ve seen: the Critical Path Method.
Thus far this only includes the System Design portion of the book.
I was “raised” on the iDesign school of architecture. To me architecture meant the high-level separation of concerns into clients, managers, engines, accessors, and resources.