Große Sammlung Java Enterprise Anti-Patterns und Architekturentscheidungen

ap001: Architekturentscheidung: Spring Boot vs Jakarta EE vs Quarkus

Fachliche Situation: Ein Team muss entscheiden, wie Spring Boot vs Jakarta EE vs Quarkus in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Spring Boot vs Jakarta EE vs Quarkus wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class SpringBootVsJakartaEEVsQuarkusDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record SpringBootVsJakartaEEVsQuarkusPolicy(boolean async, Duration timeout, int maxRetries) {
    public static SpringBootVsJakartaEEVsQuarkusPolicy enterpriseDefault() {
        return new SpringBootVsJakartaEEVsQuarkusPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class SpringBootVsJakartaEEVsQuarkusUseCase {
    private final SpringBootVsJakartaEEVsQuarkusPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap002: Architekturentscheidung: REST vs SOAP vs Messaging

Fachliche Situation: Ein Team muss entscheiden, wie REST vs SOAP vs Messaging in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu REST vs SOAP vs Messaging wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class PartnerPortalClient {
    public String submitOrder(Order order) {
        if (order.partner().usesSoap()) {
            return soapClient.call("SubmitOrder", order.toXml());
        }
        return http.post("/submitOrder", order).body();
    }
}

// Pattern: Strategy - Integrationsstil wird austauschbar und testbar.
public interface PartnerOrderGateway {
    SubmissionResult submit(Order order);
}
public final class SoapPartnerOrderGateway implements PartnerOrderGateway {
    public SubmissionResult submit(Order order) {
        return soapClient.submitOrder(order.toSoapContract());
    }
}
public final class RestPartnerOrderGateway implements PartnerOrderGateway {
    public SubmissionResult submit(Order order) {
        return http.postJson("/orders", OrderRequest.from(order));
    }
}

ap003: Architekturentscheidung: DTO vs Entity Exposure

Fachliche Situation: Ein Team muss entscheiden, wie DTO vs Entity Exposure in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu DTO vs Entity Exposure wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class DTOVsEntityExposureDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record DTOVsEntityExposurePolicy(boolean async, Duration timeout, int maxRetries) {
    public static DTOVsEntityExposurePolicy enterpriseDefault() {
        return new DTOVsEntityExposurePolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class DTOVsEntityExposureUseCase {
    private final DTOVsEntityExposurePolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap004: Architekturentscheidung: Repository vs DAO vs Port

Fachliche Situation: Ein Team muss entscheiden, wie Repository vs DAO vs Port in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Repository vs DAO vs Port wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class RepositoryVsDAOVsPortDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record RepositoryVsDAOVsPortPolicy(boolean async, Duration timeout, int maxRetries) {
    public static RepositoryVsDAOVsPortPolicy enterpriseDefault() {
        return new RepositoryVsDAOVsPortPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class RepositoryVsDAOVsPortUseCase {
    private final RepositoryVsDAOVsPortPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap005: Architekturentscheidung: Service Layer vs Use Case Layer

Fachliche Situation: Ein Team muss entscheiden, wie Service Layer vs Use Case Layer in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Service Layer vs Use Case Layer wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class ServiceLayerVsUseCaseLayerDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record ServiceLayerVsUseCaseLayerPolicy(boolean async, Duration timeout, int maxRetries) {
    public static ServiceLayerVsUseCaseLayerPolicy enterpriseDefault() {
        return new ServiceLayerVsUseCaseLayerPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class ServiceLayerVsUseCaseLayerUseCase {
    private final ServiceLayerVsUseCaseLayerPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap006: Architekturentscheidung: Synchronous HTTP vs Asynchronous Events

Fachliche Situation: Ein Team muss entscheiden, wie Synchronous HTTP vs Asynchronous Events in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Synchronous HTTP vs Asynchronous Events wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class SynchronousHTTPVsAsynchronousEventsDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record SynchronousHTTPVsAsynchronousEventsPolicy(boolean async, Duration timeout, int maxRetries) {
    public static SynchronousHTTPVsAsynchronousEventsPolicy enterpriseDefault() {
        return new SynchronousHTTPVsAsynchronousEventsPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class SynchronousHTTPVsAsynchronousEventsUseCase {
    private final SynchronousHTTPVsAsynchronousEventsPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap007: Architekturentscheidung: Monolith Modularisieren vs Microservices

Fachliche Situation: Ein Team muss entscheiden, wie Monolith Modularisieren vs Microservices in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Monolith Modularisieren vs Microservices wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class MonolithModularisierenVsMicroservicesDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record MonolithModularisierenVsMicroservicesPolicy(boolean async, Duration timeout, int maxRetries) {
    public static MonolithModularisierenVsMicroservicesPolicy enterpriseDefault() {
        return new MonolithModularisierenVsMicroservicesPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class MonolithModularisierenVsMicroservicesUseCase {
    private final MonolithModularisierenVsMicroservicesPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap008: Architekturentscheidung: JPA vs JDBC vs Stored Procedure

Fachliche Situation: Ein Team muss entscheiden, wie JPA vs JDBC vs Stored Procedure in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu JPA vs JDBC vs Stored Procedure wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class JPAVsJDBCVsStoredProcedureDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record JPAVsJDBCVsStoredProcedurePolicy(boolean async, Duration timeout, int maxRetries) {
    public static JPAVsJDBCVsStoredProcedurePolicy enterpriseDefault() {
        return new JPAVsJDBCVsStoredProcedurePolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class JPAVsJDBCVsStoredProcedureUseCase {
    private final JPAVsJDBCVsStoredProcedurePolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap009: Architekturentscheidung: Virtual Threads vs ExecutorService

Fachliche Situation: Ein Team muss entscheiden, wie Virtual Threads vs ExecutorService in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Virtual Threads vs ExecutorService wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class ImportController {
    private final ExecutorService pool = Executors.newFixedThreadPool(400);
    public void start(List<URI> files) {
        files.forEach(uri -> pool.submit(() -> importFile(uri)));
    }
}

// Pattern: Bulkhead - begrenzter Zugriff auf externe Ressourcen.
public final class ImportExecutor {
    private final Semaphore databaseSlots = new Semaphore(30);
    public void importFiles(List<URI> files) throws InterruptedException {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (URI file : files) executor.submit(() -> importWithDatabaseLimit(file));
        }
    }
    private void importWithDatabaseLimit(URI file) throws Exception {
        if (!databaseSlots.tryAcquire(10, TimeUnit.SECONDS)) throw new TimeoutException("DB busy");
        try { importFile(file); } finally { databaseSlots.release(); }
    }
}

ap010: Architekturentscheidung: CompletableFuture vs Message Queue

Fachliche Situation: Ein Team muss entscheiden, wie CompletableFuture vs Message Queue in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu CompletableFuture vs Message Queue wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class CompletableFutureVsMessageQueueDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record CompletableFutureVsMessageQueuePolicy(boolean async, Duration timeout, int maxRetries) {
    public static CompletableFutureVsMessageQueuePolicy enterpriseDefault() {
        return new CompletableFutureVsMessageQueuePolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class CompletableFutureVsMessageQueueUseCase {
    private final CompletableFutureVsMessageQueuePolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap011: Architekturentscheidung: BOM vs Parent POM

Fachliche Situation: Ein Team muss entscheiden, wie BOM vs Parent POM in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu BOM vs Parent POM wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

<dependencies>
  <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>3.3.2</version></dependency>
  <dependency><groupId>org.junit.jupiter</groupId><artifactId>junit-jupiter</artifactId><version>5.10.2</version></dependency>
</dependencies>

<!-- Pattern: Dependency Governance - Versionen zentral im BOM steuern. -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.acme.platform</groupId><artifactId>enterprise-platform-bom</artifactId><version>2026.07</version><type>pom</type><scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

ap012: Architekturentscheidung: Profiles vs Separate Pipelines

Fachliche Situation: Ein Team muss entscheiden, wie Profiles vs Separate Pipelines in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Profiles vs Separate Pipelines wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class ProfilesVsSeparatePipelinesDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record ProfilesVsSeparatePipelinesPolicy(boolean async, Duration timeout, int maxRetries) {
    public static ProfilesVsSeparatePipelinesPolicy enterpriseDefault() {
        return new ProfilesVsSeparatePipelinesPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class ProfilesVsSeparatePipelinesUseCase {
    private final ProfilesVsSeparatePipelinesPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap013: Architekturentscheidung: OpenShift Deployment vs Helm vs Kustomize

Fachliche Situation: Ein Team muss entscheiden, wie OpenShift Deployment vs Helm vs Kustomize in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu OpenShift Deployment vs Helm vs Kustomize wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

apiVersion: apps/v1
kind: Deployment
metadata: { name: order-service }
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: latest

# Pattern: Release Template - Umgebung wird über Werte gesteuert.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/order-service:1.18.0
          readinessProbe: { httpGet: { path: /actuator/health/readiness, port: 8080 } }

ap014: Architekturentscheidung: JWT vs Session vs mTLS

Fachliche Situation: Ein Team muss entscheiden, wie JWT vs Session vs mTLS in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu JWT vs Session vs mTLS wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public boolean mayApprove(HttpServletRequest request) {
    return "ADMIN".equals(request.getHeader("X-Role"));
}

// Pattern: Policy Object - Berechtigung hängt an fachlicher Regel und geprüfter Identität.
public final class ApprovalPolicy {
    public boolean mayApprove(UserPrincipal user, Order order) {
        return user.hasScope("order:approve") && order.total().isLessThan(user.approvalLimit());
    }
}

ap015: Architekturentscheidung: Batch vs Stream Processing

Fachliche Situation: Ein Team muss entscheiden, wie Batch vs Stream Processing in einer Enterprise-Landschaft eingesetzt wird, ohne aus Gewohnheit zur falschen Technik zu greifen.

Technische Entscheidung: Die Entscheidung zu Batch vs Stream Processing wird als explizite Architekturregel mit Alternativen, Grenzen und Konsequenzen dokumentiert.

Warum wichtig: Die Entscheidung verhindert Architektur-Raten und macht Alternativen nachvollziehbar.

Typischer Fehler: Entscheidung wird über Bauchgefühl, Lieblingsframework oder vorhandenen Altcode getroffen.

Bessere Lösung: Entscheidung in ADR festhalten, Zielqualität messen und Code an klaren Ports oder Policies ausrichten.

Enterprise-Einordnung: Hilft bei Architekturboards, Migrationen, Plattform-Standards und nachvollziehbaren Technologieentscheidungen.

public class BatchVsStreamProcessingDecision {
    public void execute(Order order) {
        if (System.getProperty("mode").equals("legacy")) legacyProcess(order);
        else modernProcess(order);
    }
}

// Pattern: Architecture Decision Record - Entscheidung wird explizit und testbar gemacht.
public record BatchVsStreamProcessingPolicy(boolean async, Duration timeout, int maxRetries) {
    public static BatchVsStreamProcessingPolicy enterpriseDefault() {
        return new BatchVsStreamProcessingPolicy(true, Duration.ofSeconds(3), 2);
    }
}
public final class BatchVsStreamProcessingUseCase {
    private final BatchVsStreamProcessingPolicy policy;
    public void execute(Order order) { validate(order); route(order, policy); }
}

ap016: Anti-Pattern: God Service

Fachliche Situation: In Legacy- und modernen Systemen tritt God Service häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: God Service wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class OrderService {
    public void checkout(HttpServletRequest request) throws SQLException, IOException {
        String customerNo = request.getParameter("customerNo");
        Connection c = dataSource.getConnection();
        c.prepareStatement("insert into orders(customer_no) values('" + customerNo + "')").execute();
        mail.send(customerNo, "created");
        http.post("https://billing.internal/invoice", request.getInputStream());
    }
}

// Pattern: Facade + Application Service - fachlicher Ablauf ohne Infrastrukturdetails.
public final class CheckoutUseCase {
    private final OrderRepository orders;
    private final BillingPort billing;
    private final CustomerNotificationPort notifications;
    public CheckoutResult checkout(CheckoutCommand command) {
        Order order = Order.createFor(command.customerNo(), command.lines());
        orders.save(order);
        billing.createInvoice(order.id());
        notifications.orderAccepted(order.customerNo(), order.id());
        return CheckoutResult.accepted(order.id());
    }
}

ap017: Anti-Pattern: Fat Controller

Fachliche Situation: In Legacy- und modernen Systemen tritt Fat Controller häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Fat Controller wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

@PostMapping("/orders/{id}/approve")
public ResponseEntity<?> approve(@PathVariable long id) {
    OrderEntity e = repository.findById(id).orElseThrow();
    if (e.getTotal().compareTo(new BigDecimal("10000")) > 0) e.setStatus("MANAGER_REVIEW");
    else e.setStatus("APPROVED");
    repository.save(e);
    return ResponseEntity.ok(e);
}

// Pattern: Use Case - Controller übersetzt nur HTTP in Anwendungssprache.
@PostMapping("/orders/{id}/approve")
public ResponseEntity<ApprovalResponse> approve(@PathVariable OrderId id) {
    return ResponseEntity.ok(approveOrder.approve(new ApproveOrderCommand(id)));
}
public final class ApproveOrderUseCase {
    public ApprovalResponse approve(ApproveOrderCommand command) {
        Order order = orders.get(command.orderId());
        order.approve(approvalPolicy);
        orders.save(order);
        return ApprovalResponse.from(order);
    }
}

ap018: Anti-Pattern: Anemic Domain Model

Fachliche Situation: In Legacy- und modernen Systemen tritt Anemic Domain Model häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Anemic Domain Model wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class OrderEntity {
    public BigDecimal total;
    public String status;
}
public class OrderWorkflow {
    public void approve(OrderEntity order) { order.status = "APPROVED"; }
}

// Pattern: Rich Domain Model - Invarianten liegen im Aggregat.
public final class Order {
    private OrderStatus status;
    private final Money total;
    public void approve(ApprovalPolicy policy) {
        if (!policy.canApprove(total)) throw new ApprovalDenied(total);
        this.status = OrderStatus.APPROVED;
    }
}

ap019: Anti-Pattern: Transaction Script

Fachliche Situation: In Legacy- und modernen Systemen tritt Transaction Script häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Transaction Script wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class TransactionScriptService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class TransactionScriptUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap020: Anti-Pattern: Static Helper Hell

Fachliche Situation: In Legacy- und modernen Systemen tritt Static Helper Hell häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Static Helper Hell wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class StaticHelperHellService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class StaticHelperHellUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap021: Anti-Pattern: Service Locator Missbrauch

Fachliche Situation: In Legacy- und modernen Systemen tritt Service Locator Missbrauch häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Service Locator Missbrauch wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ServiceLocatorMissbrauchService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class ServiceLocatorMissbrauchUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap022: Anti-Pattern: Hidden Coupling über Singleton

Fachliche Situation: In Legacy- und modernen Systemen tritt Hidden Coupling über Singleton häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Hidden Coupling über Singleton wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class HiddenCouplingberSingletonService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class HiddenCouplingberSingletonUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap023: Anti-Pattern: Business Logic im Mapper

Fachliche Situation: In Legacy- und modernen Systemen tritt Business Logic im Mapper häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Business Logic im Mapper wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class BusinessLogicImMapperService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class BusinessLogicImMapperUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap024: Anti-Pattern: DTO Explosion

Fachliche Situation: In Legacy- und modernen Systemen tritt DTO Explosion häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: DTO Explosion wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class DTOExplosionService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class DTOExplosionUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap025: Anti-Pattern: Package by Layer ohne Fachschnitt

Fachliche Situation: In Legacy- und modernen Systemen tritt Package by Layer ohne Fachschnitt häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Package by Layer ohne Fachschnitt wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class PackageByLayerOhneFachschnittService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class PackageByLayerOhneFachschnittUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap026: Anti-Pattern: Controller kennt Datenbank

Fachliche Situation: In Legacy- und modernen Systemen tritt Controller kennt Datenbank häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Controller kennt Datenbank wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ControllerKenntDatenbankService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class ControllerKenntDatenbankUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap027: Anti-Pattern: Domain kennt HTTP

Fachliche Situation: In Legacy- und modernen Systemen tritt Domain kennt HTTP häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Domain kennt HTTP wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class DomainKenntHTTPService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class DomainKenntHTTPUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap028: Anti-Pattern: Utility-Klasse als Architektur

Fachliche Situation: In Legacy- und modernen Systemen tritt Utility-Klasse als Architektur häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Utility-Klasse als Architektur wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class UtilityKlasseAlsArchitekturService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class UtilityKlasseAlsArchitekturUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap029: Anti-Pattern: Zyklische Module

Fachliche Situation: In Legacy- und modernen Systemen tritt Zyklische Module häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Zyklische Module wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ZyklischeModuleService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class ZyklischeModuleUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap030: Anti-Pattern: Keine Ports und Adapter

Fachliche Situation: In Legacy- und modernen Systemen tritt Keine Ports und Adapter häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Der Schnitt trennt Fachlogik, Infrastruktur und API-Vertrag dauerhaft.

Typischer Fehler: Keine Ports und Adapter wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class KeinePortsUndAdapterService {
    public Object handle(Map<String,Object> payload) {
        String orderNo = (String) payload.get("orderNo");
        jdbc.update("update orders set status='DONE' where order_no='" + orderNo + "'");
        return payload;
    }
}

// Pattern: Ports and Adapters - fachliche Logik kennt keine Infrastruktur.
public final class KeinePortsUndAdapterUseCase {
    private final OrderRepository orders;
    private final AuditPort audit;
    public OrderResult handle(OrderCommand command) {
        Order order = orders.get(command.orderNo());
        order.markProcessed();
        orders.save(order);
        audit.record("ORDER_PROCESSED", order.orderNo().value());
        return OrderResult.from(order);
    }
}

ap031: Anti-Pattern: N+1 Query

Fachliche Situation: In Legacy- und modernen Systemen tritt N+1 Query häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: N+1 Query wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

List<OrderEntity> orders = em.createQuery("select o from OrderEntity o", OrderEntity.class).getResultList();
for (OrderEntity order : orders) {
    System.out.println(order.getLines().size()); // löst je Order eine weitere Query aus
}

// Pattern: Query Object - benötigte Daten werden bewusst geladen.
String jpql = "select new com.acme.OrderSummary(o.id, o.orderNo, count(l.id)) "
    + "from OrderEntity o left join o.lines l "
    + "group by o.id, o.orderNo";
List<OrderSummary> orders = em.createQuery(jpql, OrderSummary.class)
    .setMaxResults(200)
    .getResultList();

ap032: Anti-Pattern: Open Session in View

Fachliche Situation: In Legacy- und modernen Systemen tritt Open Session in View häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Open Session in View wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap033: Anti-Pattern: Lazy Loading im JSON

Fachliche Situation: In Legacy- und modernen Systemen tritt Lazy Loading im JSON häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Lazy Loading im JSON wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap034: Anti-Pattern: Entity direkt als API-Vertrag

Fachliche Situation: In Legacy- und modernen Systemen tritt Entity direkt als API-Vertrag häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Entity direkt als API-Vertrag wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap035: Anti-Pattern: Mega-Repository

Fachliche Situation: In Legacy- und modernen Systemen tritt Mega-Repository häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Mega-Repository wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap036: Anti-Pattern: Unbegrenzte Abfragen

Fachliche Situation: In Legacy- und modernen Systemen tritt Unbegrenzte Abfragen häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Unbegrenzte Abfragen wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap037: Anti-Pattern: Transaktion über Remote Calls

Fachliche Situation: In Legacy- und modernen Systemen tritt Transaktion über Remote Calls häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Transaktion über Remote Calls wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

@Transactional
public void approve(String orderNo) {
    OrderEntity order = repository.get(orderNo);
    partnerClient.reserve(orderNo); // Remote Call hält DB-Transaktion offen
    order.setStatus("APPROVED");
}

// Pattern: Transactional Outbox - DB-Transaktion und Integration entkoppeln.
@Transactional
public void approve(String orderNo) {
    Order order = orders.get(orderNo);
    order.approve();
    orders.save(order);
    outbox.add(new PartnerReservationRequested(orderNo, order.version()));
}

ap038: Anti-Pattern: Read/Write ohne Optimistic Locking

Fachliche Situation: In Legacy- und modernen Systemen tritt Read/Write ohne Optimistic Locking häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Read/Write ohne Optimistic Locking wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

@Entity
public class OrderEntity {
    @Id Long id;
    String status;
}

// Pattern: Optimistic Locking - parallele Änderungen werden erkannt.
@Entity
public class OrderEntity {
    @Id Long id;
    @Version long version;
    @Enumerated(EnumType.STRING) OrderStatus status;
}

ap039: Anti-Pattern: Datenbank als Message Queue

Fachliche Situation: In Legacy- und modernen Systemen tritt Datenbank als Message Queue häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Datenbank als Message Queue wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap040: Anti-Pattern: Stored Procedure Wildwuchs

Fachliche Situation: In Legacy- und modernen Systemen tritt Stored Procedure Wildwuchs häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Stored Procedure Wildwuchs wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap041: Anti-Pattern: Audit nur im Logfile

Fachliche Situation: In Legacy- und modernen Systemen tritt Audit nur im Logfile häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Audit nur im Logfile wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap042: Anti-Pattern: Sensible Daten unmaskiert

Fachliche Situation: In Legacy- und modernen Systemen tritt Sensible Daten unmaskiert häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Sensible Daten unmaskiert wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap043: Anti-Pattern: Migration ohne Versionierung

Fachliche Situation: In Legacy- und modernen Systemen tritt Migration ohne Versionierung häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Migration ohne Versionierung wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap044: Anti-Pattern: Batch ohne Checkpoint

Fachliche Situation: In Legacy- und modernen Systemen tritt Batch ohne Checkpoint häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Batch ohne Checkpoint wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap045: Anti-Pattern: Fachstatus als String-Salat

Fachliche Situation: In Legacy- und modernen Systemen tritt Fachstatus als String-Salat häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Datenzugriff bleibt kontrollierbar, testbar und transaktionssicher.

Typischer Fehler: Fachstatus als String-Salat wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public List<OrderEntity> loadOrders(String status) {
    return em.createQuery("select o from OrderEntity o where o.status='" + status + "'", OrderEntity.class)
             .getResultList();
}

// Pattern: Repository + Specification - Abfrage ist begrenzt und typisiert.
public Page<OrderProjection> findOrders(OrderSearchCriteria criteria, PageRequest page) {
    return orderRepository.findByStatusAndCreatedAfter(
        criteria.status(), criteria.from(), page.limit(100));
}

ap046: Anti-Pattern: Chatty REST API

Fachliche Situation: In Legacy- und modernen Systemen tritt Chatty REST API häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Chatty REST API wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ChattyRESTAPIClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class ChattyRESTAPIPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap047: Anti-Pattern: REST als RPC missbraucht

Fachliche Situation: In Legacy- und modernen Systemen tritt REST als RPC missbraucht häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: REST als RPC missbraucht wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class RESTAlsRPCMissbrauchtClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class RESTAlsRPCMissbrauchtPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap048: Anti-Pattern: SOAP Vertrag ohne Kompatibilität

Fachliche Situation: In Legacy- und modernen Systemen tritt SOAP Vertrag ohne Kompatibilität häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: SOAP Vertrag ohne Kompatibilität wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class SOAPVertragOhneKompatibilittClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class SOAPVertragOhneKompatibilittPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap049: Anti-Pattern: Gemeinsame DTO-Bibliothek zwischen Systemen

Fachliche Situation: In Legacy- und modernen Systemen tritt Gemeinsame DTO-Bibliothek zwischen Systemen häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Gemeinsame DTO-Bibliothek zwischen Systemen wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class GemeinsameDTOBibliothekZwischenSystemenClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class GemeinsameDTOBibliothekZwischenSystemenPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap050: Anti-Pattern: Schnittstelle ohne Idempotenz

Fachliche Situation: In Legacy- und modernen Systemen tritt Schnittstelle ohne Idempotenz häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Schnittstelle ohne Idempotenz wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

@PostMapping("/payments")
public PaymentResult pay(@RequestBody PaymentCommand command) {
    return paymentService.charge(command.orderNo(), command.amount());
}

// Pattern: Idempotency Key - Wiederholungen erzeugen keine Doppelbuchung.
@PostMapping("/payments")
public PaymentResult pay(@RequestHeader("Idempotency-Key") String key,
                         @RequestBody PaymentCommand command) {
    return paymentService.chargeOnce(key, command.orderNo(), command.amount());
}

ap051: Anti-Pattern: Event ohne Schema-Version

Fachliche Situation: In Legacy- und modernen Systemen tritt Event ohne Schema-Version häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Event ohne Schema-Version wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class EventOhneSchemaVersionClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class EventOhneSchemaVersionPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap052: Anti-Pattern: Outbox vergessen

Fachliche Situation: In Legacy- und modernen Systemen tritt Outbox vergessen häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Outbox vergessen wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

@Transactional
public void create(Order order) {
    orderRepository.save(order);
    kafka.send("orders", new OrderCreated(order.id())); // kann nach Commit verloren gehen
}

// Pattern: Transactional Outbox - Event wird atomar mit dem Aggregat gespeichert.
@Transactional
public void create(Order order) {
    orderRepository.save(order);
    outboxRepository.append(new OutboxEvent("OrderCreated", order.id().value(), order.toEventJson()));
}
public void publishPending() {
    outboxRepository.lockNextBatch(100).forEach(event -> kafka.send(event.topic(), event.key(), event.payload()));
}

ap053: Anti-Pattern: Exactly Once Illusion

Fachliche Situation: In Legacy- und modernen Systemen tritt Exactly Once Illusion häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Exactly Once Illusion wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ExactlyOnceIllusionClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class ExactlyOnceIllusionPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap054: Anti-Pattern: Kafka Topic als Datenbank

Fachliche Situation: In Legacy- und modernen Systemen tritt Kafka Topic als Datenbank häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Kafka Topic als Datenbank wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class KafkaTopicAlsDatenbankClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class KafkaTopicAlsDatenbankPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap055: Anti-Pattern: Retry ohne Backoff

Fachliche Situation: In Legacy- und modernen Systemen tritt Retry ohne Backoff häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Retry ohne Backoff wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

for (int i = 0; i < 20; i++) {
    try { return partnerClient.call(request); }
    catch (IOException ex) { /* sofort wiederholen */ }
}
throw new PartnerUnavailable();

// Pattern: Retry with Backoff - Wiederholung schützt statt Lastspitzen zu erzeugen.
RetryPolicy policy = RetryPolicy.builder()
    .maxAttempts(3)
    .delay(Duration.ofMillis(200))
    .jitter(Duration.ofMillis(100))
    .retryOn(IOException.class)
    .build();
return retry.execute(policy, () -> partnerClient.call(request));

ap056: Anti-Pattern: Timeout fehlt

Fachliche Situation: In Legacy- und modernen Systemen tritt Timeout fehlt häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Timeout fehlt wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

HttpRequest request = HttpRequest.newBuilder(endpoint.resolve("/price"))
    .POST(BodyPublishers.ofString(json))
    .build();
return http.send(request, BodyHandlers.ofString()).body();

// Pattern: Timeout Budget - jeder externe Aufruf hat eine klare Obergrenze.
HttpRequest request = HttpRequest.newBuilder(endpoint.resolve("/price"))
    .timeout(Duration.ofSeconds(2))
    .POST(BodyPublishers.ofString(json))
    .build();
return http.send(request, BodyHandlers.ofString()).body();

ap057: Anti-Pattern: Circuit Breaker fehlt

Fachliche Situation: In Legacy- und modernen Systemen tritt Circuit Breaker fehlt häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Circuit Breaker fehlt wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class CircuitBreakerFehltClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class CircuitBreakerFehltPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap058: Anti-Pattern: Partner-System direkt im Domain-Service

Fachliche Situation: In Legacy- und modernen Systemen tritt Partner-System direkt im Domain-Service häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Partner-System direkt im Domain-Service wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class PartnerSystemDirektImDomainServiceClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class PartnerSystemDirektImDomainServicePartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap059: Anti-Pattern: API ohne Correlation-ID

Fachliche Situation: In Legacy- und modernen Systemen tritt API ohne Correlation-ID häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: API ohne Correlation-ID wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class APIOhneCorrelationIDClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class APIOhneCorrelationIDPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap060: Anti-Pattern: Upload ohne Größenlimit

Fachliche Situation: In Legacy- und modernen Systemen tritt Upload ohne Größenlimit häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Systemgrenzen bleiben stabil, kompatibel und fehlertolerant.

Typischer Fehler: Upload ohne Größenlimit wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class UploadOhneGrssenlimitClient {
    public void send(Order order) {
        http.post("/partner", order.toString());
    }
}

// Pattern: Adapter + Contract - externer Vertrag ist versioniert und isoliert.
public final class UploadOhneGrssenlimitPartnerAdapter implements PartnerPort {
    public PartnerResult send(Order order) {
        PartnerOrderV2 request = PartnerOrderV2.from(order);
        return PartnerResult.from(http.postJson("/api/v2/orders", request));
    }
}

ap061: Anti-Pattern: Path Traversal bei Downloads

Fachliche Situation: In Legacy- und modernen Systemen tritt Path Traversal bei Downloads häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Path Traversal bei Downloads wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public Path download(String fileName) {
    return Paths.get("/srv/contracts/" + fileName);
}

// Pattern: Input Validation - Pfad bleibt innerhalb des erlaubten Verzeichnisses.
public Path download(String fileName) {
    Path base = Paths.get("/srv/contracts").toAbsolutePath().normalize();
    Path resolved = base.resolve(fileName).normalize();
    if (!resolved.startsWith(base)) throw new AccessDeniedException(fileName);
    return resolved;
}

ap062: Anti-Pattern: Unsichere Java-Serialization

Fachliche Situation: In Legacy- und modernen Systemen tritt Unsichere Java-Serialization häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Unsichere Java-Serialization wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

try (ObjectInputStream in = new ObjectInputStream(request.getInputStream())) {
    ImportCommand command = (ImportCommand) in.readObject();
    importService.run(command);
}

// Pattern: Explicit Contract - JSON DTO statt unsicherer Objektserialisierung.
ImportCommandDto dto = objectMapper.readValue(request.getInputStream(), ImportCommandDto.class);
validator.validate(dto);
importService.run(dto.toCommand());

ap063: Anti-Pattern: XML External Entity

Fachliche Situation: In Legacy- und modernen Systemen tritt XML External Entity häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: XML External Entity wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
Document doc = factory.newDocumentBuilder().parse(xmlInputStream);

// Pattern: Secure Parser Configuration - externe Entitäten sind deaktiviert.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setExpandEntityReferences(false);
Document doc = factory.newDocumentBuilder().parse(xmlInputStream);

ap064: Anti-Pattern: CSV Injection

Fachliche Situation: In Legacy- und modernen Systemen tritt CSV Injection häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: CSV Injection wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

writer.println(customer.name() + "," + customer.comment());

// Pattern: Output Encoding - Tabellenprogramme interpretieren keine Formeln.
String safeComment = customer.comment().replaceAll("^([=+\-@])", "'$1");
writer.printf("%s,%s%n", csv.escape(customer.name()), csv.escape(safeComment));

ap065: Anti-Pattern: Secrets im Git Repository

Fachliche Situation: In Legacy- und modernen Systemen tritt Secrets im Git Repository häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Secrets im Git Repository wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class SecretsImGitRepositoryPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap066: Anti-Pattern: Admin-Rolle als String-Vergleich

Fachliche Situation: In Legacy- und modernen Systemen tritt Admin-Rolle als String-Vergleich häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Admin-Rolle als String-Vergleich wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class AdminRolleAlsStringVergleichPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap067: Anti-Pattern: Fehlende Output-Encoding

Fachliche Situation: In Legacy- und modernen Systemen tritt Fehlende Output-Encoding häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Fehlende Output-Encoding wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class FehlendeOutputEncodingPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap068: Anti-Pattern: Unvalidierte Redirect-URL

Fachliche Situation: In Legacy- und modernen Systemen tritt Unvalidierte Redirect-URL häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Unvalidierte Redirect-URL wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class UnvalidierteRedirectURLPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap069: Anti-Pattern: Upload ohne Content-Prüfung

Fachliche Situation: In Legacy- und modernen Systemen tritt Upload ohne Content-Prüfung häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Upload ohne Content-Prüfung wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class UploadOhneContentPrfungPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap070: Anti-Pattern: Fehlende Rate Limits

Fachliche Situation: In Legacy- und modernen Systemen tritt Fehlende Rate Limits häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Fehlende Rate Limits wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class FehlendeRateLimitsPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap071: Anti-Pattern: Security nur im Controller

Fachliche Situation: In Legacy- und modernen Systemen tritt Security nur im Controller häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Security nur im Controller wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class SecurityNurImControllerPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap072: Anti-Pattern: Audit ohne Fachkontext

Fachliche Situation: In Legacy- und modernen Systemen tritt Audit ohne Fachkontext häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Audit ohne Fachkontext wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class AuditOhneFachkontextPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap073: Anti-Pattern: Persönliche Daten im Log

Fachliche Situation: In Legacy- und modernen Systemen tritt Persönliche Daten im Log häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: Persönliche Daten im Log wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class PersnlicheDatenImLogPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap074: Anti-Pattern: CORS Wildcard im Enterprise

Fachliche Situation: In Legacy- und modernen Systemen tritt CORS Wildcard im Enterprise häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: CORS Wildcard im Enterprise wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class CORSWildcardImEnterprisePolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap075: Anti-Pattern: TLS Zertifikatsprüfung deaktiviert

Fachliche Situation: In Legacy- und modernen Systemen tritt TLS Zertifikatsprüfung deaktiviert häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Angriffsfläche, Datenschutz- und Compliance-Risiken werden reduziert.

Typischer Fehler: TLS Zertifikatsprüfung deaktiviert wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public boolean allowed(String role) {
    return role.equals("ADMIN");
}

// Pattern: Policy Object - Berechtigung ist fachlich und zentral prüfbar.
public final class TLSZertifikatsprfungDeaktiviertPolicy {
    public boolean allowed(UserPrincipal user, BusinessAction action) {
        return user.hasPermission(action.requiredPermission()) && user.tenant().equals(action.tenant());
    }
}

ap076: Anti-Pattern: Unbegrenzter Thread-Pool

Fachliche Situation: In Legacy- und modernen Systemen tritt Unbegrenzter Thread-Pool häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Unbegrenzter Thread-Pool wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

ExecutorService executor = Executors.newCachedThreadPool();
for (ImportJob job : jobs) {
    executor.submit(() -> importService.run(job));
}

// Pattern: Bulkhead - Parallelität wird pro Ressource begrenzt.
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    8, 32, 30, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(500),
    new ThreadPoolExecutor.CallerRunsPolicy());
jobs.forEach(job -> executor.submit(() -> importService.run(job)));

ap077: Anti-Pattern: parallelStream in Enterprise Services

Fachliche Situation: In Legacy- und modernen Systemen tritt parallelStream in Enterprise Services häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: parallelStream in Enterprise Services wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class ParallelStreamInEnterpriseServicesCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class ParallelStreamInEnterpriseServicesCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap078: Anti-Pattern: CompletableFuture ohne Executor

Fachliche Situation: In Legacy- und modernen Systemen tritt CompletableFuture ohne Executor häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: CompletableFuture ohne Executor wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

CompletableFuture<OrderView> view = CompletableFuture.supplyAsync(() -> loadOrder(orderNo))
    .thenCombine(CompletableFuture.supplyAsync(() -> loadInvoice(orderNo)), OrderView::new);

// Pattern: Dedicated Executor - blockierende IO-Arbeit nutzt einen eigenen Pool.
ExecutorService ioExecutor = Executors.newFixedThreadPool(24);
CompletableFuture<Order> order = CompletableFuture.supplyAsync(() -> loadOrder(orderNo), ioExecutor);
CompletableFuture<Invoice> invoice = CompletableFuture.supplyAsync(() -> loadInvoice(orderNo), ioExecutor);
OrderView view = order.thenCombine(invoice, OrderView::new).orTimeout(2, TimeUnit.SECONDS).join();

ap079: Anti-Pattern: Future.get ohne Timeout

Fachliche Situation: In Legacy- und modernen Systemen tritt Future.get ohne Timeout häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Future.get ohne Timeout wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class FutureGetOhneTimeoutCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class FutureGetOhneTimeoutCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap080: Anti-Pattern: ThreadLocal Leak

Fachliche Situation: In Legacy- und modernen Systemen tritt ThreadLocal Leak häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: ThreadLocal Leak wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public final class TenantContext {
    static final ThreadLocal<String> TENANT = new ThreadLocal<>();
    public static void set(String tenant) { TENANT.set(tenant); }
}

// Pattern: Scoped Context - Kontext wird übergeben und sicher geschlossen.
try (TenantScope ignored = tenantContext.open(request.tenant())) {
    orderUseCase.execute(command);
}
public void close() { currentTenant.remove(); }

ap081: Anti-Pattern: volatile als Lock-Ersatz

Fachliche Situation: In Legacy- und modernen Systemen tritt volatile als Lock-Ersatz häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: volatile als Lock-Ersatz wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class VolatileAlsLockErsatzCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class VolatileAlsLockErsatzCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap082: Anti-Pattern: Atomic ohne Invariantenschutz

Fachliche Situation: In Legacy- und modernen Systemen tritt Atomic ohne Invariantenschutz häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Atomic ohne Invariantenschutz wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class AtomicOhneInvariantenschutzCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class AtomicOhneInvariantenschutzCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap083: Anti-Pattern: BlockingQueue ohne Backpressure

Fachliche Situation: In Legacy- und modernen Systemen tritt BlockingQueue ohne Backpressure häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: BlockingQueue ohne Backpressure wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

BlockingQueue<Event> queue = new LinkedBlockingQueue<>();
public void publish(Event event) { queue.add(event); }

// Pattern: Backpressure - Queue ist begrenzt und Überlast wird sichtbar.
BlockingQueue<Event> queue = new ArrayBlockingQueue<>(10_000);
public boolean publish(Event event) throws InterruptedException {
    return queue.offer(event, 250, TimeUnit.MILLISECONDS);
}

ap084: Anti-Pattern: Cache ohne Eviction

Fachliche Situation: In Legacy- und modernen Systemen tritt Cache ohne Eviction häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Cache ohne Eviction wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class CacheOhneEvictionCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class CacheOhneEvictionCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap085: Anti-Pattern: Synchronized auf Remote Call

Fachliche Situation: In Legacy- und modernen Systemen tritt Synchronized auf Remote Call häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Synchronized auf Remote Call wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class SynchronizedAufRemoteCallCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}

// Pattern: Thread-safe Cache - Nebenläufigkeit und Begrenzung sind explizit.
public final class SynchronizedAufRemoteCallCache {
    private final ConcurrentMap<String, CompletableFuture<Order>> cache = new ConcurrentHashMap<>();
    public Order get(String key) {
        return cache.computeIfAbsent(key, k -> CompletableFuture.supplyAsync(() -> load(k)))
                    .orTimeout(1, TimeUnit.SECONDS).join();
    }
}

ap086: Anti-Pattern: Virtuelle Threads für CPU-Arbeit

Fachliche Situation: In Legacy- und modernen Systemen tritt Virtuelle Threads für CPU-Arbeit häufig auf, wenn Zeitdruck, unklare Grenzen oder fehlende Reviews zusammenkommen.

Technische Entscheidung: Das Anti-Pattern wird erkannt und durch eine kleinere, fachlich benannte Struktur ersetzt.

Warum wichtig: Parallelität wird begrenzt, messbar und reproduzierbar testbar.

Typischer Fehler: Virtuelle Threads für CPU-Arbeit wird als pragmatische Abkürzung akzeptiert und später von mehreren Teams kopiert.

Bessere Lösung: Fachliche Verantwortlichkeiten schneiden, Infrastruktur isolieren, Tests ergänzen und die Entscheidung dokumentieren.

Enterprise-Einordnung: Reduziert Wartungskosten, Produktionsrisiken und Kopplung in großen Java-Enterprise-Systemlandschaften.

public class VirtuelleThreadsFrCPUArbeitCache {
    private final Map<String, Order> cache = new HashMap<>();
    public Order get(String key) { return cache.computeIfAbsent(key, this::load); }
}