Skip to main content

Anti-Pattern: Monolithic BFF (Backend For Frontend)

Description​

A Backend For Frontend (BFF) is typically a design pattern where a dedicated backend services a specific frontend user experience (e.g., Mobile App vs Web App).

The Monolithic BFF Anti-Pattern occurs when this "BFF" logic is not a separate lightweight service, but a massive Folder/Namespace inside the Core Monolith that couples the Monolith directly to the UI specifics.

Evidence​

  • Module: FRONT.
  • Files: FrontApiBiz (containing 71 classes/files).
  • Structure: A distinct namespace WepBusiness.FRONT.FrontApiBiz that mirrors UI requirements.

Impact​

  1. Coupling: The Monolith now knows about "Page Slugs", "View Models", and "Checkout Steps".
  2. Logic Drift:
    • The FrontApi might implement CalculatePrice differently than OMGT (Backoffice Order Management).
    • Result: A student sees price X on the website, but the staff sees price Y in the Backoffice.
  3. Bloat: The core domain is polluted with presentation concerns (FrontApi.ViewModels).

Remediation​

  1. Extract to API: Move FrontApi to a separate deployable unit (e.g., a .NET Core WebAPI or Next.js Backend).
  2. Consumer Driven Contracts: The Frontend should define what it needs, and the Monolith should expose generic APIs (e.g., GetProductPrice), which the BFF aggregates.
  3. Use Core Logic: Ensure FrontApi calls OMGT.PriceService instead of reinventing the wheel.