07 March 2014

Software Architecture Traps

As developers, we like to solve problems with code. Sometimes business problems aren't hard enough, and without even thinking about it, we expand the problem so it becomes harder. We want to solve all problems in the same general category as that problem. Once and for all, so we can reuse it later. Maybe we want to build a framework or integrate multiple frameworks (ORM, IOC, AOP, etc.) to solve our problems once and for all. Well, I wish I had run across this video sooner.


Sometimes the pain I experience while coding something doesn't indicate that I need to bring in (or create) another framework to avoid that pain. Maybe that pain is simply telling me that there is a non-technical problem (i.e. analysis problem) that a framework isn't going to solve (but might hide).

I realized I had done this with my LocalBus project. If I wasn't trying to fit a square peg in a round hole, then the "overhead" of writing wire-up code wouldn't have been so painful. I would never have needed to write it.

I also really liked how this video shows handler wire-up with dependencies (e.g. repositories). It's manual, but it is also customizable (varying dependencies between use cases), and (using functional language features) it's pretty low overhead.

No comments: