JavaScript · OOP · Tech Lead · Architecture
You are leading a redesign of a large JS domain layer that mixed anemic data objects with scattered business rules. How would you structure OOP (or FP) boundaries?
Short Interview Answer
Define clear domain entities/services with invariants in one place; keep infrastructure (HTTP/DB/UI) outside; prefer small composable types over deep class trees.
Detailed Explanation
Start by identifying bounded contexts and ubiquitous language. Model invariants on entities/value objects (classes or factories that validate on construction). Put use-cases in application services that orchestrate domain objects — avoid UI components owning rules. Prefer composition of policies/strategies over a mega-base `Entity`. Decide immutability defaults for value objects. For JS/TS, TypeScript interfaces + modules often beat deep inheritance. Establish testing strategy: pure domain unit tests without DOM/network. Migration: strangler-fig new modules beside legacy anemic models; forbid new business logic in controllers. Measure success by reduced duplication and fewer cross-layer leaks.
Interview Tip
Talk migration and team conventions, not only UML.
Common Mistake
Rewriting everything into a textbook GoF pattern catalog without incremental delivery.