Abstract: This paper describes an application architecture that maximizes long term maintainability and feature deliverability for a certain class of applications. It covers effective use of boundaries, application roles, and application of design patterns to create an architecture that separates the core business logic from the delivery mechanisms. Problems with current approaches are covered. It finishes with a migration strategy for existing applications.
Title: Untitled for now, open to suggestions
Length: ~20,000 words, may become longer
Outline:
- Introduction
- System Design: Object roles, boundaries, protocols, patterns, and delivery mechanisms
- TDD implementation of use cases, forms, models, and other object roles
- TDD implementation of HTTP delivery mechanism using Sinatra
- Problems withs Rails & Rails style MVC approach to web applications
- The ideal stack: calling out gems that exemplify qualities mentioned in previous parts of the paper
- Wrap up & conclusion
- How to migrate and redsign current systems
Now for snippet:
Effective software design focuses on enforcing boundaries and applying design patterns. Maintainable systems have boundaries in the right places. Design patterns organize code in predictable and understandable ways. Both strategies actively defend against technical debt and encourage technical investment. It is common knowledge that you must invest to achieve long term success. You must invest in an application's architecture to maximize its long term success, feature deliverability, and scalability. It is time to apply the same long term financial planning to software applications.
Technical debt is the cost of previous technical decisions. Engineering work can be done in a quick and dirty way; doing exactly what is needed for today in a way that may not work in the future. It is about making a choice: quick and messy, or slower and cleaner. Every programmer has made to make this decision "oh, I'll just hack this in” then written FIXME directly above it." Then probably thought to themselves how to actually implement it correctly. Applications often collapse under their technical debt. Applications become impossible to maintain. The only way to pay back the debt is to start over. This is an unfortunate situation but it is avoidable. This situation happens when engineering teams (for whatever reason) decide to accumulate more technical debt. The decision usually comes from business requirements and short delivery dates. Teams must actively decide to pay back their debt in terms of technical investments. Projects incur most technical debt in the early stages. This is the most delicate time in an application's life time. Just like real life childhood, the decisions (good, bad, awesome, horrible) made in the formative years have a strong last impact. The signs of excellent parenting live on people grow into well adjusted individuals. Horrible or abusive parenting often leave scars for life which are difficult or impossible to heal without serious effort. This paper is about making technical investment from t0 to raise a happy, mature, and maintainable program. Children need proper nourishment from the beginning. Applications require proper separation of concerns, boundaries, objects roles, and design patterns.