The Gallery

A single method orchestrates seven services, creating a structural coupling trap where any change to payment, fraud, inventory, or notification touches the same method.

class PaymentProcessor {
  constructor(
    private db, private stripe, private mailer, private inventory,
    private analytics, private taxCalc, private fraudDetection
  ) {}

  async processPayment(orderId, cardToken) {
    const order = await this.db.orders.findById(orderId);
    const tax = this.taxCalc.calculate(order.items, order.shippingAddress.state);
    order.tax = tax;
    const fraudScore = await this.fraudDetection.evaluate({ amount: order.total + tax, card: cardToken, ... });
    if (fraudScore > 0.8) { await this.mailer.send(...); await this.analytics.track('fraud_hold', ...); return {...}; }
    const charge = await this.stripe.charges.create({ amount: Math.round((order.total + tax) * 100), ... });
    for (const item of order.items) {
      await this.inventory.decrement(item.sku, item.quantity);
      if (await this.inventory.getStock(item.sku) < 10) { await this.mailer.send('warehouse@company.com', ...); }
    }
    order.status = 'paid'; order.chargeId = charge.id; await this.db.orders.save(order);
    await this.mailer.send(order.customerEmail, 'Payment Received', `Charge: $${order.total + tax}`);
    await this.analytics.track('payment_success', { orderId, amount: order.total + tax });
    return { status: 'paid', chargeId: charge.id };
  }
}

Domain entities import infrastructure directly, and a near-cycle forms between Product and PricingService.

graph TD
  subgraph API["API Layer"]
    OrderController; UserController
  end
  subgraph Services["Service Layer"]
    OrderService; PricingService; UserService
  end
  subgraph Domain["Domain Layer"]
    Order; User; Product
  end
  subgraph Infra["Infrastructure Layer"]
    PostgresClient; RedisCache; StripeClient
  end
  OrderController --> OrderService
  UserController --> UserService
  UserService --> OrderService
  OrderService --> Order
  OrderService --> PostgresClient
  PricingService --> Product
  PricingService --> StripeClient
  Order --> PostgresClient
  User --> RedisCache
  Product --> PricingService
  classDef critical fill:#ff6b6b,stroke:#c92a2a,color:#fff
  classDef warning fill:#ffd43b,stroke:#e67700
  classDef clean fill:#51cf66,stroke:#2b8a3e,color:#fff
  class Order,User,Product critical
  class OrderService,PricingService,UserService warning
  class OrderController,UserController,PostgresClient,RedisCache,StripeClient clean

auth → user → notification → auth forms a strongly connected component — Go refuses to compile it.

graph TD
  subgraph pkg["pkg/"]
    auth["auth"]; user["user"]; notification["notification"]; billing["billing"]
  end
  auth --> user
  user --> notification
  notification -.->|circular| auth
  billing --> user
  classDef critical fill:#ff6b6b,stroke:#c92a2a,color:#fff
  classDef warning fill:#ffd43b,stroke:#e67700
  class auth,user,notification critical
  class billing warning

Dependencies flow inward, infra implements domain ports, no cycles. brooks-lint reports clean code as clean — and still offers one forward-looking suggestion.

graph TD
  subgraph API["API Layer"]
    OrderController; UserController
  end
  subgraph Application["Application Layer"]
    OrderService; UserService
  end
  subgraph Domain["Domain Layer"]
    OrderModel["Order"]; UserModel["User"]; OrderRepository["OrderRepository (interface)"]; UserRepository["UserRepository (interface)"]
  end
  subgraph Infra["Infrastructure Layer"]
    JpaOrderRepository; JpaUserRepository
  end
  OrderController --> OrderService
  UserController --> UserService
  OrderService --> OrderModel
  OrderService --> OrderRepository
  UserService --> UserModel
  UserService --> UserRepository
  JpaOrderRepository --> OrderRepository
  JpaUserRepository --> UserRepository
  classDef clean fill:#51cf66,stroke:#2b8a3e,color:#fff
  class OrderController,UserController,OrderService,UserService,OrderModel,UserModel,OrderRepository,UserRepository,JpaOrderRepository,JpaUserRepository clean

Adding a currency means editing six files in six unrelated layers — three Critical findings that share one root cause.

Seven mocks per test, 14 lines of setup vs 6 of assertions — the service is never tested against a real collaborator, and the return value is never checked.

it('should place an order successfully', () => {
  const mockDb = mock<Database>();
  const mockPayment = mock<PaymentGateway>();
  const mockInventory = mock<InventoryService>();
  const mockMailer = mock<MailService>();
  const mockAudit = mock<AuditLogger>();
  const mockCache = mock<CacheService>();
  const mockMetrics = mock<MetricsCollector>();
  const service = new OrderService(mockDb, mockPayment, mockInventory, mockMailer, mockAudit, mockCache, mockMetrics);
  const result = await service.placeOrder('1', 'item-1', 2);

  expect(mockPayment.charge).toHaveBeenCalledWith('ch_1', 2000);
  expect(mockInventory.check).toHaveBeenCalledWith('item-1', 2);
  expect(mockMailer.send).toHaveBeenCalled();
  expect(mockAudit.log).toHaveBeenCalledWith('ORDER_PLACED', expect.anything());
  expect(mockCache.invalidate).toHaveBeenCalledWith('orders:1');
  expect(mockMetrics.increment).toHaveBeenCalledWith('orders.placed');
});

Only 16% of tests are unit tests; an E2E-heavy suite takes ~9 minutes and blocks fast CI feedback.

tests/
├── e2e/           47 tests, avg 8s each   (~6 min)
├── integration/   83 tests, avg 2s each   (~3 min)
└── unit/          24 tests, avg 10ms each (~0.2s)

Total: 154 tests, ~9 min
Actual  ratio:  Unit 16% : Integration 54% : E2E 30%
Target  ratio:  Unit 70% : Integration 20% : E2E 10%