Belajar Software Architecture and Design Patterns - DTO, Entity & Value Object | Belajar Software Architecture and Design Patterns

#Pendahuluan

Sebagian besar kode backend kotor berawal dari satu kesalahan klasik: memakai satu bentuk objek untuk segalanya — biasanya ORM model — dari HTTP request sampai domain logic. Episode ini menegakkan disiplin tiga jenis objek: DTO, Entity, dan Value Object.

#Konsep

#Tiga Jenis Objek, Tiga Peran

Jenis	Identitas?	Mutable?	Berisi Logika?	Contoh
DTO	Tidak	Boleh	Tidak (data + validasi bentuk)	`CreateOrderDto`
Entity	Ya (`id`)	Ya (lifecycle)	Ya — perilaku domain	`Order`
Value Object	Tidak (dibedakan nilai)	Immutable	Ya — self-validating	`Money`, `Email`, `Address`

Aturan alurnya sederhana namun ketat:

100%

#Value Object: Immutable & Self-Validating

VO punya dua properti superpower: ia tidak bisa dalam keadaan tidak valid (validasi di konstruktor) dan aman dibagikan karena tak pernah berubah. Dua VO paling instruktif:

Kenapa Money bukan int?

- int 1000 = Rp1.000 atau 1000 cent? -> Money(amount, currency)
- Penjumlahan lintas currency harus ditolak: Money(100,'IDR').add(Money(5,'USD')) -> error di konstruktor/add
- Pembulatan uang punya aturan domain -> logika hidup DI DALAM VO, bukan tersebar
 
Kenapa Email bukan string?
- Validasi format sekali di konstruktor -> seluruh sistem yakin Email selalu valid
- Type safety: parameter bertipe Email tak menerima "string apapun"

#Anemic vs Rich Domain Model

Anemic: objek domain hanya getter/setter; semua logika di service luar. Mudah ditulis, tapi bisnis tersebar dan invarian mudah dilanggar. Rich: perilaku tinggal bersama datanya (order.addItem(), money.add()). Keseimbangan pragmatisnya: entity inti layak rich; objek pendukung CRUD polos boleh anemic. Kita dalami ulang lewat aggregate di episode 19.

#Real-World Implementasi

export class CreateOrderDto {
  @IsEmail() customerEmail!: string;
  @IsArray() items!: OrderItemDto[];
}
 
export class Money {                       // VO
  private constructor(
    public readonly amountMinor: number,
    public readonly currency: 'IDR' | 'USD',
  ) {
    if (amountMinor < 0) throw new InvalidMoneyError();
  }
  static of(a: number, c: 'IDR' | 'USD') { return new Money(a, c); }
  add(o: Money): Money {
    if (o.currency !== this.currency) throw new CurrencyMismatchError();
    return new Money(this.amountMinor + o.amountMinor, this.currency);
  }
}

type CreateOrderDTO struct {
    CustomerEmail string     `json:"customer_email"`
    Items         []ItemDTO  `json:"items"`
}
 
type Address struct {                     // VO
    Street, City, PostalCode string
}
 
func NewAddress(street, city, postal string) (Address, error) {
    if street == "" || postal == "" {
        return Address{}, errors.New("address incomplete")
    }
    return Address{street, city, postal}, nil // tak ada setter -> immutable efektif
}

final class StoreOrderRequest extends FormRequest {   // input DTO + validasi
    public function rules(): array {
        return ['customer_email' => ['required', 'email'],
                'items' => ['required', 'array', 'min:1']];
    }
}
 
final class MoneyCast implements CastsAttributes {    // VO via attribute casting
    public function get($model, $key, $value, $attrs): Money {
        return Money::of((int) $value, $model->currency);
    }
    public function set($model, $key, $value, $attrs): int {
        return $value instanceof Money ? $value->amountMinor : (int) $value;
    }
}
// Output DTO: OrderResource::make($order) di controller.

Perhatikan idiom tiap ekosistem: NestJS deklaratif via decorator, Go eksplisit via konstruktor, Laravel menyatukan VO ke ORM lewat cast — tujuan akhirnya sama.

#Praktik

Target outline: model Money + Address sebagai VO dan alirkan DTO→entity→response DTO.

export class Order {                          // entity
  private items: CartItem[] = [];
  constructor(
    public readonly id: string,
    private readonly email: Email,            // VO
    private total: Money,                     // VO
  ) {}
 
  addItem(item: CartItem): void {             // perilaku menjaga invarian
    this.total = this.total.add(item.price.multiply(item.qty));
    this.items.push(item);
  }
  snapshot(): OrderResponseDto {              // mapping keluar
    return { id: this.id, total: this.total.amountMinor,
             currency: this.total.currency };
  }
}

[x] Email/Money/Address: validasi di konstruktor, tanpa setter publik
[x] Money.add menolak campur currency (test merah->hijau)
[x] Alur request: DTO divalidasi -> entity dibangun via method perilaku
[x] Response DTO dipeteks eksplisit (snapshot/resource), bukan dump entity
[x] Grep bukti: TIDAK ada ORM model yang lolos keluar sebagai response mentah

Tip

Mulai dari VO bernilai ekonomi tinggi dulu (Money, Email, Quantity). Mereka kecil, dampak bug-nya mahal, dan menjadi pintu masuk paling murah menuju rich domain.

#Penutup

Rangkuman episode ini:

DTO transfer antar boundary tanpa logika; Entity punya identitas+lifecycle; VO immutable, dibedakan nilai, self-validating.
Mapping antar lapisan eksplisit — jangan biarkan ORM model bocor keluar API.
Idiom stack: class-validator NestJS, struct+konstruktor Fiber, Form Request/API Resource/Castable Laravel.

Episode 9 mulai arsitektur layering sesungguhnya: Repository Pattern & DAO — abstraksi persistence yang membuat episode-4 latihan DIP kalian jadi fondasi nyata. Sampai jumpa!