Modeling Domain Logic with Scala Case Classes and Sealed Traits

The Problem: Fragile Type Checking

When modeling business domains—such as payment processing or order management—developers often rely on generic classes or large sets of nullable fields to handle different states. This leads to "defensive programming," where the code is littered with if (type == "CREDIT_CARD") checks and manual null checks. The risk is high: adding a new payment type often requires searching the entire codebase for every single if/else block to ensure the new type is handled, making the system prone to runtime MatchError or silent failures.

The solution is to use Algebraic Data Types (ADTs). By combining sealed traits and case classes, you can move the burden of correctness from your memory to the Scala compiler.

Defining the Domain with Sealed Traits

A sealed trait is a trait that can only be extended within the same file. This restriction is a powerful tool for the compiler. When you pattern match on a sealed trait, the compiler knows every possible subtype that exists. If you miss one, it will issue a warning at compile-time, preventing a production crash.

Case classes complement this by providing value-based equality. Unlike standard classes, where == checks if two references point to the same memory address, case classes check if the data inside the objects is identical. This makes them ideal for Data Transfer Objects (DTOs) and state management.

Worked Example: Payment Processing

Consider a system that needs to handle different payment methods. Each method requires different data, but all must be processable by a single payment gateway.

sealed trait PaymentMethod

case class CreditCard(number: String, expiry: String, cvv: String) extends PaymentMethod
case class PayPal(email: String) extends PaymentMethod
case class BankTransfer(accountNumber: String, routingNumber: String) extends PaymentMethod

object PaymentProcessor {
  def process(method: PaymentMethod): String = method match {
    case CreditCard(num, _, _) => s"Processing credit card ending in ${num.takeRight(4)}"
    case PayPal(email)         => s"Redirecting to PayPal for $email"
    case BankTransfer(acc, _)  => s"Initiating transfer from account $acc"
  }
}

Implementation Details:

• Execution: Run this in the Scala REPL or a standard sbt project (Scala 2.13+ or 3.x).
• Permissions: No special system permissions required; this is standard JVM application code.
• Verification: If you add a case class Crypto(wallet: String) extends PaymentMethod but do not update the process method, the compiler will warn: "match may not be exhaustive".

Managing State with Non-Destructive Mutation

Case class fields are val (immutable) by default. To change a value, you use the built-in copy method. This creates a new instance of the class with specific fields updated, leaving the original object untouched. This is critical for thread safety in concurrent environments.

val initialPayment = CreditCard("123456789", "12/25", "123")
val updatedPayment = initialPayment.copy(expiry = "01/26")

// Verification of value-based equality
val paymentA = PayPal("[contact removed]")
val paymentB = PayPal("[contact removed]")
println(paymentA == paymentB) // Output: true

Trade-offs and Limitations

While powerful, this approach has practical limits:

• Memory Overhead: Because case classes encourage immutability, updating a deeply nested object requires copying every level of the hierarchy. In high-throughput systems creating millions of short-lived objects, this can increase Garbage Collection (GC) pressure.
• Verbosity in Nesting: If you have a User containing an Address containing a ZipCode, updating the zip code via copy becomes cumbersome: user.copy(address = user.address.copy(zip = ZipCode("12345"))). For deeply nested structures, consider using a lens library like Monocle.

Practical Verification

To ensure your domain model is robust, perform these three checks:

1. Exhaustivity Check: Intentionally comment out one case arm in a pattern match on a sealed trait. Verify that the compiler generates a warning.
2. Equality Check: Create two separate instances of a case class with identical values. Use == to confirm they are treated as equal.
3. Immutability Check: Attempt to reassign a field (e.g., payment.number = "new"). The compiler should throw an error because fields are immutable by default.