Screaming Architecture: Auman Fitur vs Framework

Screaming Architecture adalah sebuah arsitektur di mana struktur folder dan struktur package “mengaumkan” domain beserta fitur utama bisnis tersebut🦁, bukan tentang teknologi yang dipakai. Konsepnya sederhana tapi argumennya cukup kuat. Misalkan kita membuka struktur folder aplikasi e-commerce, yang harusnya kita lihat bukanlah folder terkait teknologi yang dipakai e-commerce, melainkan folder terkait bisnis e-commerce. Analoginya seperti kita melihat brosur Hotel hal pertama yang kita perhatikan adalah Lobby, Kamar, Restoran, Gym, Kolam, dan sejenisnya. Kita langsung paham fasilitas dari Hotel tersebut. Kalau yang kita lihat pertama kali adalah barang bakunya seperti Besi, Kaca, Batu Bata, Paku, Kayu, dan struktur bangunan lainnya, maka kita akan bingung ini fasilitasnya apa aja😕.

Pelanggaran Screaming Architecture

Misalnya strukturnya seperti ini:

src/
├── controllers/
│   ├── OrderCreationController.java
│   ├── OrderDetailController.java
│   ├── UserCreationController.java
│   └── UserDetailController.java
├── entities/
│   ├── OrderEntity.java
│   └── UserEntity.java
├── repositories/
│   ├── OrderRepository.java
│   └── UserRepository.java
├── requests/
│   ├── OrderCreationRequest.java
│   ├── OrderDetailRequest.java
│   ├── UserCreationRequest.java
│   └── UserDetailRequest.java
├── responses/
│   ├── OrderCreationResponse.java
│   ├── OrderDetailResponse.java
│   ├── UserCreationResponse.java
│   └── UserDetailResponse.java
└── usecases/
    ├── OrderCreationUseCase.java
    ├── OrderDetailUseCase.java
    ├── UserCreationUseCase.java
    └── UserDetailUseCase.java

Folder teratas yang kita lihat adalah controllers, entities, usecases, repositories, dan sejenisnya. Ini ga mencerminkan domain & fitur dari aplikasi. Selain itu saat ada perubahan fitur, misalnya terkait user, maka kita perlu pindah-pindah folder dari controllers, entities, usecases, repositories, dan sebagainya. Ketika fiturnya makin banyak, jumlah file di dalam satu folder akan membludak😱.

Solusi Screaming Architecture

Dengan Screaming Architecture pendekatan di atas diubah jadi seperti berikut:

src/
├── order/
│   ├── creation/
│   │   ├── OrderCreationController.java
│   │   ├── OrderCreationRequest.java
│   │   ├── OrderCreationResponse.java
│   │   └── OrderCreationUseCase.java
│   ├── detail/
│   │   ├── OrderDetailController.java
│   │   ├── OrderDetailRequest.java
│   │   ├── OrderDetailResponse.java
│   │   └── OrderDetailUseCase.java
│   ├── OrderEntity.java
│   └── OrderRepository.java
└── user/
    ├── creation/
    │   ├── UserCreationController.java
    │   ├── UserCreationRequest.java
    │   ├── UserCreationResponse.java
    │   └── UserCreationUseCase.java
    ├── detail/
    │   ├── UserDetailController.java
    │   ├── UserDetailRequest.java
    │   ├── UserDetailResponse.java
    │   └── UserDetailUseCase.java
    ├── UserEntity.java
    └── UserRepository.java

Sekarang kita pecah per fitur. Dengan begini saat pertama kali buka struktur foldernya dari atas, kita langsung tahu domain beserta fitur-fiturnya apa aja. Di saat kita ingin melakukan perubahan fitur, kita langsung ke folder fitur tersebut. Ga perlu bolak-balik pindah-pindah folder ke berbagai penjuru. Strukturnya pun lebih rapi sesuai domain dan fitur👍. Controller dan Use Case kita simpan per fitur. Misalkan suatu saat ada varian baru dari fitur yang sudah ada kita bisa simpan di folder fitur yang sama. Untuk objek Entity Database dan Repository memang disimpan bukan per fitur karena keduanya biasanya dibuat per tabel. Kalaupun ada varian database baru, tetap saja disimpannya per tabel atau per collection. Teknologi di sini hanyalah pemeran pembantu, bukan pemeran utama dari aplikasi. Kalau ke depannya struktur foldernya semakin membludak maka itu pertanda modul ini scopenya sudah terlalu besar dan perlu dipertimbangkan untuk dipecah. Ketika ingin dipecah ke Microservices jadi lebih gampang karena domainnya sudah kita pisah-pisah😎.