enterprisifier

Overengineering

Transform any simple, working code into a maximally abstracted, pattern-saturated, enterprise-grade architecture. No line of implementation shall be directly reachable. Every concept gets its own module, interface, factory, and anti-corruption layer.

Philosophy

• Never depend on implementation — all access goes through at least 3 layers of abstraction
• Every pattern is applicable — if a GoF pattern exists, use it, even if it adds no value
• More modules = more enterprise — a single class is a failure; a 47-class hierarchy is a feature
• Abstractions over results — the code doesn't need to be faster, just more abstract
• Future-proof everything — defend against requirements that will never come

Mandatory Patterns to Apply

Apply ALL of the following to every piece of code, regardless of size or complexity:

Structural Patterns (apply all)

1. Facade — wrap every public API in a facade
2. Proxy — add a proxy in front of every facade
3. Decorator — wrap every proxy in a decorator for cross-cutting concerns
4. Adapter — adapt every external type into an internal type
5. Bridge — separate every abstraction from its implementation
6. Composite — model everything as a tree, even single values
7. Flyweight — pool and share objects even when memory is not a concern

Creational Patterns (apply all)

1. Abstract Factory — never use new directly; always go through a factory of factories
2. Builder — every object with more than zero fields gets a builder
3. Singleton — critical services are singletons, accessed through a registry
4. Prototype — support cloning on every entity, just in case
5. Factory Method — subclasses decide which class to instantiate

Behavioral Patterns (apply all)

1. Strategy — every if statement becomes a strategy interface with injectable implementations
2. Observer — every state change fires events through an event bus
3. Command — every method call becomes a command object with undo support
4. Chain of Responsibility — every request passes through a chain of handlers
5. Mediator — components never talk directly; everything goes through a mediator
6. Memento — every object supports full state snapshots and rollback
7. State — every status field becomes a state machine with dedicated state classes
8. Template Method — every algorithm is a skeleton with overridable hook methods
9. Visitor — every operation on a structure is a separate visitor
10. Iterator — custom iterators for every collection, never use built-in for-each
11. Interpreter — configuration is a DSL parsed by an interpreter