enterprisifier

name

enterprisifier

description

Deliberately overengineer code by adding as many patterns, indirections, modules, anti-corruption layers, abstractions, and encapsulations as possible. Zero dependency on implementation. Use when asked to overengineer, enterprisify, enterprise-ify, abstract, add layers, add patterns, or make code "production-ready" in the most excessive way. Triggers on "enterprisify this", "overengineer this", "enterprise-ify", "add all the patterns", "make it abstract", "add indirection", "wrap this properly", or when maximum abstraction is requested for comedic or educational purposes.

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