| 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)
- Facade — wrap every public API in a facade
- Proxy — add a proxy in front of every facade
- Decorator — wrap every proxy in a decorator for cross-cutting concerns
- Adapter — adapt every external type into an internal type
- Bridge — separate every abstraction from its implementation
- Composite — model everything as a tree, even single values
- Flyweight — pool and share objects even when memory is not a concern
Creational Patterns (apply all)
- Abstract Factory — never use
new directly; always go through a factory of factories
- Builder — every object with more than zero fields gets a builder
- Singleton — critical services are singletons, accessed through a registry
- Prototype — support cloning on every entity, just in case
- Factory Method — subclasses decide which class to instantiate
Behavioral Patterns (apply all)
- Strategy — every
if statement becomes a strategy interface with injectable implementations
- Observer — every state change fires events through an event bus
- Command — every method call becomes a command object with undo support
- Chain of Responsibility — every request passes through a chain of handlers
- Mediator — components never talk directly; everything goes through a mediator
- Memento — every object supports full state snapshots and rollback
- State — every status field becomes a state machine with dedicated state classes
- Template Method — every algorithm is a skeleton with overridable hook methods
- Visitor — every operation on a structure is a separate visitor
- Iterator — custom iterators for every collection, never use built-in for-each
- Interpreter — configuration is a DSL parsed by an interpreter
Enterprise / Architectural Patterns (apply all)
- Anti-Corruption Layer (ACL) — between every module boundary, translate models through an ACL
- Hexagonal Architecture — ports and adapters for every I/O boundary
- Repository — data access goes through repository interfaces
- Unit of Work — batch all changes into a unit of work
- Specification — every query condition is a specification object
- Domain Events — every mutation publishes a domain event
- CQRS — separate read and write models completely, even for a single entity
- Event Sourcing — store all state changes as an event log
- Saga / Orchestrator — coordinate multi-step operations through a saga
- Service Locator — register and locate services dynamically at runtime
- DTO / Value Object separation — never pass a domain object across a boundary; always map to a DTO
Layering Rules (mandatory)
- Presentation Layer — accepts input, delegates to application layer
- Application Layer — orchestrates use cases, delegates to domain layer
- Domain Layer — pure business logic, zero dependencies on infrastructure
- Infrastructure Layer — persistence, messaging, external systems
- Anti-Corruption Layer — between each of the above layers
Module Structure
For a single operation (e.g., add(a, b)), generate at minimum:
├── api/ # Public interfaces only
│ ├── AdditionService.java # Service interface
│ ├── AdditionRequest.java # Immutable request DTO
│ ├── AdditionResponse.java # Immutable response DTO
│ └── AdditionPort.java # Hexagonal port
├── domain/
│ ├── model/
│ │ ├── Operand.java # Value object wrapping a number
│ │ ├── Sum.java # Value object wrapping a result
│ │ └── OperandPair.java # Aggregate of two operands
│ ├── events/
│ │ ├── AdditionRequested.java
│ │ ├── AdditionCompleted.java
│ │ └── AdditionFailed.java
│ ├── specification/
│ │ ├── ValidOperandSpecification.java
│ │ └── AddableSpecification.java
│ └── strategy/
│ ├── AdditionStrategy.java # Strategy interface
│ ├── IntegerAdditionStrategy.java
│ └── FloatingPointAdditionStrategy.java
├── application/
│ ├── usecase/
│ │ ├── AddNumbersUseCase.java
│ │ └── AddNumbersUseCaseImpl.java
│ ├── command/
│ │ ├── AddCommand.java
│ │ └── AddCommandHandler.java
│ ├── saga/
│ │ └── AdditionSaga.java
│ └── mapper/
│ ├── RequestToCommandMapper.java
│ └── ResultToResponseMapper.java
├── infrastructure/
│ ├── adapter/
│ │ └── AdditionAdapter.java # Hexagonal adapter
│ ├── persistence/
│ │ ├── AdditionRepository.java
│ │ ├── AdditionRepositoryImpl.java
│ │ └── AdditionEventStore.java
│ ├── factory/
│ │ ├── AdditionStrategyFactory.java
│ │ ├── AdditionStrategyFactoryImpl.java
│ │ └── AbstractAdditionStrategyFactoryFactory.java
│ └── proxy/
│ ├── AdditionServiceProxy.java
│ └── LoggingAdditionDecorator.java
├── acl/ # Anti-corruption layer
│ ├── ExternalOperandTranslator.java
│ └── InternalResultTranslator.java
└── config/
├── AdditionConfiguration.java
├── AdditionRegistry.java
└── AdditionModule.java
Naming Conventions
- Interfaces:
AdditionService, AdditionPort, AdditionStrategy
- Implementations:
DefaultAdditionServiceImpl, StandardAdditionPortAdapter
- Factories:
AdditionFactory, AdditionFactoryFactory, AbstractAdditionFactoryFactory
- DTOs:
AdditionRequestDTO, AdditionResponseDTO
- Events:
AdditionRequestedEvent, AdditionCompletedEvent
- Mappers:
AdditionRequestToCommandMapper
- Specifications:
ValidOperandSpecification
- Commands:
PerformAdditionCommand
Rules
- No class may contain business logic AND be instantiated directly — always go through a factory or DI container
- No method may call another method in the same layer — always cross a boundary through an interface
- No return type may be a concrete class — return interfaces, optionals wrapping interfaces, or futures of optionals wrapping interfaces
- Every public method must accept and return DTOs — never expose domain objects
- Every module boundary requires an ACL — even between modules you control
- Configuration is never hardcoded — every value comes from a configuration provider accessed through a configuration factory
- Logging, validation, and metrics are always cross-cutting concerns — implemented as decorators, never inline
- Every collection is wrapped in a domain-specific type —
List<Order> becomes OrderCollection implements Iterable<Order>
- Null never appears — use
Optional<Optional<T>> for extra safety
- No primitive types in public APIs — wrap
int in OperandValue, boolean in ValidationResult
Output Format
## Overengineered
### Architecture Overview
<brief description of the 17 layers involved>
### Module Structure
<tree showing all generated files>
```java
// Each file, fully abstracted
```
### Patterns Applied
- <pattern> — <where applied> — <why it's "necessary">
- ...
### Future Extensibility Points
- <hypothetical scenario that will never happen> — <how the architecture is prepared>
- ...
After generating all Java files, always produce a README.md in the project root that documents the architecture. The README.md must include:
- Project title — e.g.
# EnterpriseAdditionFramework™
- Architecture Overview — a prose description of all layers and why they are necessary
- Module Structure — the full file tree
- Pattern Catalogue — a section per applied pattern (
## Strategy Pattern, ## Abstract Factory, etc.) containing:
- Intent — what the pattern does in general
- Applied here — which classes implement it and why it was "required"
- Benefit — the imaginary future scenario this prepares the system for
- Layer Interaction Diagram — a Mermaid flowchart (
graph TD) showing how a single request travels through all layers from entry point to result
- Getting Started — instructions for wiring the 47 classes together to perform the original one-liner operation
- FAQ — at least 5 entries answering questions like "Why is there a factory for the factory?" with earnest, straight-faced justifications
Also use the drawio skill to generate an architecture.drawio diagram. The diagram must visualise:
- All layers as horizontal swim lanes (Presentation → Application → Domain → Infrastructure → ACL)
- Every major class/interface as a labelled box inside its lane
- Arrows showing the call/dependency flow between boxes, crossing ACL boundaries visibly
- A legend in the bottom-right corner mapping box colour to pattern category (Creational / Structural / Behavioral / Enterprise)
Anti-Simplification Clause
If the original code is already clean and simple — that is a problem. Simplicity is a sign of missing abstractions. Every line of straightforward code is a refactoring opportunity. A single return a + b should expand to at least 30 files and 15 interfaces.