Arsitektur Angular Praktis untuk kehidupan nyata

Sebagian besar kursus arsitektur Angular mengajarkan teori. Ini bukan.

Di sini Anda belajar mendeteksi masalah nyata, membuat keputusan berdasarkan situasi, dan membangun sistem yang bertahan seiring pertumbuhan tim, perubahan produk, dan waktu berlalu.

Dua puluh modul. Berorientasi pada praktik. Tidak ada bantalan.

---

INDEX — Arsitektur Angular praktis untuk kehidupan nyata

---

Modul 0 — Basis Sistem

Poin 0 bukan modul konten. Ini adalah cara pandang yang akan Anda gunakan sepanjang peta jalan.

Sebelum membicarakan masalah spesifik di Angular, Anda perlu menjawab pertanyaan:

Bagaimana Anda melihat aplikasi yang tidak Anda ketahui dan memutuskan apakah aplikasi itu baik atau buruk?

Ada empat keterampilan dasar untuk itu.

---

1. Analisis aplikasi tanpa menyentuh kode

Pembacaan pertama suatu aplikasi tidak ada di editor. Itu ada di dalam struktur. Sebelum membuka satu file, Anda dapat mengekstrak informasi:

• Apa nama foldernya? Apakah nama-nama tersebut menjelaskan apa yang mereka lakukan?
• Apakah ada folder shared yang lebih berat dari yang lainnya?
• Berapa banyak tingkat sarang yang dimiliki struktur tersebut?
• Apakah modul atau fitur memiliki nama domain atau nama teknis?
• Dimana layanannya? Fitur longgar atau dalam?

Ini sudah memberi tahu Anda banyak hal tentang apakah siapa pun yang membuat aplikasi berpikir dalam istilah bisnis atau dalam lapisan teknis.

---

2. Tinjau arsitektur secara praktis

Meninjau bukanlah membaca kode dari atas ke bawah. Itu mengajukan pertanyaan dengan kriteria:

• Di manakah logika bisnis berada?
• Siapa yang tahu apa yang ada di setiap lapisan?
• Berapa banyak situs yang harus Anda ubah untuk menambahkan fitur baru?
• Apakah ada ketergantungan yang mengarah ke arah yang salah?

Seorang arsitek senior tidak memulai dengan komponen yang paling rumit. Mulailah dengan titik risiko tertinggi: layanan bersama, status global, dan lapisan akses data.

---

3. Deteksi masalah sebelum pemrograman

Sebagian besar kerusakan arsitektur terjadi pada keputusan awal yang tampaknya tidak relevan:

• "Saya menempatkan ini pada layanan bersama untuk saat ini"
• "Komponen induk menangani keadaan ini, lalu kita pindahkan"
• "Kami menggunakan NgRx untuk semuanya, jadi konsisten"

Keputusan-keputusan ini memiliki konsekuensi nyata beberapa bulan kemudian. Kriteria arsitekturalnya adalah mengetahui apa yang dibeli oleh setiap keputusan dan utang apa yang timbul.

---

4. Ubah teori menjadi daftar periksa nyata

Setiap konsep yang akan kita lihat dalam peta jalan ini - komponen pintar/bodoh, penempatan negara bagian, layanan dewa, dll. - harus diakhiri dengan pertanyaan yang dapat Anda tanyakan pada diri sendiri saat meninjau kode sebenarnya:

• Apakah komponen ini mengetahui dari mana data tersebut berasal?
• Apakah layanan ini memiliki lebih dari satu alasan untuk berubah?
• Apakah negara bagian ini ada di dua tempat berbeda?

Jika Anda tidak dapat mengubah sebuah konsep menjadi pertanyaan tinjauan, Anda belum menginternalisasikannya.

---

Modul 1 — Cara menganalisis aplikasi Angular tanpa menyentuh kode

Tinjauan arsitektur pertama dilakukan sebelum membuka editor. Hanya dari struktur folder dan nama file Anda sudah dapat mengekstraksi sinyal kualitas yang jelas. Inilah yang akan dilakukan oleh seorang arsitek senior dalam 10 menit pertama dengan aplikasi yang tidak dikenal.

Mengapa itu penting?

• Jika Anda membutuhkan waktu lama untuk mendeteksi masalah arsitektural, biaya untuk memperbaikinya akan meningkat secara eksponensial.
• Struktur yang dirancang dengan buruk sejak hari pertama menjadi hutang teknis yang menghalangi tim beberapa bulan kemudian.
• Mengembangkan penilaian visual yang cepat memungkinkan Anda membuat keputusan yang lebih baik sebelum menulis satu baris kode.

Langkah 1 — Baca struktur folder sebagai peta

Struktur folder adalah keputusan arsitektur pertama yang terlihat. Ini memberi tahu Anda bagaimana tim mengatur dunia mental mereka: apakah mereka berpikir dalam kaitannya dengan teknologi atau dalam kaitannya dengan bisnis?

Apa itu fitur?

Fitur adalah fungsionalitas bisnis yang lengkap. Bukan jenis file. Bukan lapisan teknis.

Bayangkan sebuah aplikasi e-niaga. Fitur-fiturnya adalah:

• Katalog produk
• Keranjang belanja
• Proses pembayaran
• Profil pengguna
• Manajemen pesanan

Masing-masing adalah bagian dari bisnis yang masuk akal tersendiri. Seorang pengguna masuk, menelusuri katalog, menambahkan ke keranjang, check out. Itu adalah fitur-fiturnya.

Model 1 — Pengorganisasian berdasarkan lapisan teknis (bermasalah dalam skala besar)

Inilah yang dilakukan hampir semua orang saat memulai karena terlihat rapi:

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

Masalah sebenarnya: Anda harus mengubah alur pembayaran. Untuk memahami apa yang terlibat, Anda menavigasi di antara tiga folder berbeda — Anda mencari komponen di components/, layanan di services/, model di models/. Jika ada pipa checkout tertentu, maka di pipes/ dicampur dengan pipa dari fitur lain.

Untuk mengubah satu fitur, Anda menavigasi seluruh aplikasi. Itu digabungkan berdasarkan struktur. Saat tim berkembang, dua orang yang mengerjakan fitur berbeda terus-menerus menyentuh folder yang sama → konflik di git, kesulitan mengetahui siapa yang memiliki apa.

Model 2 — Organisasi berdasarkan fitur (skala apa)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

Mengapa ini berhasil: Saat Anda mengetuk checkout, semua yang ada di checkout akan menyatu. Pengembang baru tahu persis di mana mencarinya. Satu orang dapat memiliki seluruh fitur. Anda dapat menghapus seluruh fitur dengan menghapus foldernya saja. Konflik Git antar fitur yang berbeda hampir hilang seluruhnya.

Aturan utama: jika Anda menghapus suatu fitur, bisakah Anda menghapus seluruh foldernya tanpa menyentuh apa pun lagi? Jika jawabannya ya, maka fitur tersebut terisolasi dengan baik. Jika Anda harus mencari potongan di seluruh aplikasi, ternyata tidak.

Langkah 2 — Baca namanya

Nama adalah dokumentasi. Nama yang buruk menyembunyikan niat dan menambah beban kognitif pada setiap orang yang membaca kode tersebut.

shared/ — apa yang harus dikandungnya dan apa yang tidak boleh dicantumkan

shared/ ditujukan untuk hal-hal yang menggunakan banyak fitur dan TIDAK memiliki logika bisnisnya sendiri.

Benar di shared/:

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

Itu adalah bagian UI yang dapat digunakan kembali atau utilitas murni. Mereka tidak tahu apa-apa tentang bisnis ini. ButtonComponent tidak mengetahui apakah itu tombol checkout atau profil pengguna. Dia hanya tahu bagaimana menjadi sebuah tombol.

Salah di shared/:

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Saat Anda melihat layanan dengan logika bisnis di dalam shared/, itu berarti seseorang tidak tahu di mana harus meletakkannya dan meletakkannya di sana. Seiring waktu shared/ menjadi aplikasi yang mencakup semua hal.

core/ — apa itu dan apa yang bukan

core/ ditujukan untuk infrastruktur tunggal yang memerlukan seluruh aplikasi, satu kali.

Benar di core/:

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

Salah di core/:

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Ini adalah hal-hal yang dibuat satu kali dan memengaruhi keseluruhan aplikasi. Pencegat autentikasi mencegat semua permintaan HTTP untuk seluruh aplikasi, itulah sebabnya ia berada di core/.

Nama tidak jelas — tanda bahaya

Nama yang samar-samar adalah keputusan yang tertunda. Saat seseorang membuat data.service.ts, mereka belum memutuskan data apa yang dibicarakan oleh layanan tersebut.

apa yang kamu lihat	Apa artinya
shared/ sangat besar	Segala sesuatu yang tidak cocok di tempat lain. Ini menjadi tas campuran.
common/	Sama seperti shared/, tetapi namanya lebih buruk. Tanpa kriteria apa yang masuk.
utils/ dengan layanan	Logika bisnis disamarkan sebagai utilitas. Bendera merah yang serius.
helpers/	Sama seperti utils/. Nama itu tidak menjelaskan apa pun tentang tanggung jawab.
components/ di akar	Tidak ada organisasi berdasarkan domain. Semua komponen menjadi satu.
core/ dengan 40 file	Inti yang didefinisikan dengan buruk. shared/ digunakan sebagai yang kedua.
app.service.ts	Pelayanan dewa yang menunggu untuk berkembang. Sinyal alarm maksimum.
data.service.ts	Data tentang apa? Tanggung jawab yang tidak terbatas dari namanya.
helper.service.ts	Itu berakhir menjadi layanan dengan metode yang tidak terkait.
main.component.ts	Apa itu "utama"? Nama umum yang menyembunyikan tanggung jawab nyata.

Aturan nama: Jika nama file tidak memberi tahu Anda apa sebenarnya fungsinya, mungkin file tersebut berfungsi terlalu banyak atau lokasinya buruk.

Contoh nyata nama yang tidak jelas dan apa yang disembunyikannya:

• utils/format.ts dengan 800 baris: campuran format tanggal + validasi formulir + transformasi API.
• helper.service.ts: berakhir menjadi pelayanan dewa dengan metode yang tidak berhubungan.
• app.service.ts: layanan yang disebut sebagai keseluruhan aplikasi yang memiliki tanggung jawab atas keseluruhan aplikasi.

Langkah 3 — Menghitung dan mengukur tanpa membuka file

Sebelum membaca kode, Anda dapat melakukan pengamatan berikut langsung dari strukturnya:

Ukuran komponen sebagai tanda

Tanda	Apa yang ditunjukkannya?
+300-400 baris dalam satu komponen	Anda hampir selalu melakukan terlalu banyak. Ini bukan aturan mutlak tetapi perlu diselidiki.
+10 masukan dan keluaran	API yang terlalu rumit. Calon akan dibagi menjadi beberapa komponen.
Panggilan HTTP langsung di komponen	Gabungkan presentasi dengan akses data. Lapisan layanan hilang.
1-2 komponen per fitur	Mereka mungkin berbuat terlalu banyak. Kurangnya perpecahan internal.
+20 penyedia global	Terlalu banyak logika negara dan terpusat. Tidak semuanya harus bersifat global.

Layanan global — bahaya providedIn: 'root'

Layanan global berarti bahwa komponen apa pun dari fitur apa pun dapat memasukkan dan menggunakannya. Hal ini menciptakan ketergantungan yang tidak terlihat antara fitur-fitur yang seharusnya independen.

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

Langkah 4 — app.module.ts atau app.config.ts: apa yang harus dicari

Dalam aplikasi dengan modul (Angular <17 atau lawas)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

Modul fitur harus dimuat dengan lambat (sesuai permintaan), tidak diimpor langsung ke modul root. Jika semuanya ada di sini, semuanya dimuat saat startup meskipun pengguna tidak pernah membutuhkannya.

Dalam aplikasi mandiri (Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

Aturan konfigurasi global: Konfigurasi global hanya boleh memiliki infrastruktur yang memengaruhi keseluruhan aplikasi: router dengan pemuatan lambat, HttpClient dengan pencegat global, animasi, layanan infrastruktur tunggal (auth, logger, penangan kesalahan). Jika Anda melihat layanan fitur dalam konfigurasi global, seseorang mendaftarkan sesuatu secara global untuk kenyamanan, bukan kebutuhan.

Daftar periksa lengkap — Pembacaan pertama aplikasi Angular

Struktur

• Apakah strukturnya diatur berdasarkan fitur (domain bisnis) atau berdasarkan lapisan teknis?
• Bisakah saya menghapus seluruh fitur dengan menghapus foldernya saja tanpa menyentuh apa pun?
• Apakah fitur memiliki nama domain bisnis (checkout, catalog) atau nama teknis (list, form, detail)?
• Apakah ada folder dengan nama yang tidak jelas: utils, helpers, common, misc, data?

shared/ dan core/

• Apakah shared/ hanya berisi komponen dan utilitas UI tanpa logika bisnis?
• Apakah core/ hanya berisi infrastruktur tunggal (pencegat, penjaga, layanan autentikasi)?
• Apakah ada layanan dengan logika bisnis dalam shared/?
• Apakah core/ memiliki komponen fitur atau layanan domain?

Layanan dan penyedia

• Apakah layanan bisnis sesuai fitur Anda atau longgar secara global?
• Apakah ada lebih dari 20 penyedia global?
• Apakah modul root atau app.config.ts mengimpor modul fitur secara langsung (tanpa malas)?
• Apakah ada layanan dengan providedIn: 'root' yang harus bersifat lokal untuk suatu fitur?

Nama

• Apakah nama file menjelaskan fungsinya dengan tepat?
• Apakah ada file yang namanya dapat diterapkan pada bagian mana pun dari aplikasi?
• Apakah ada file bernama app.service.ts, data.service.ts atau helper.service.ts?
• Apakah shared/ lebih berbobot dibandingkan fitur individual mana pun?

Latihan

Telusuri proyek Angular publik apa pun di GitHub — bisa milik Anda sendiri atau proyek sumber terbuka. Tanpa membuka file apa pun, cukup melihat struktur dan nama folder:

1. Model organisasi apa yang Anda gunakan: fitur atau lapisan teknis?
2. Nama apa yang membuat Anda ragu atau curiga?
3. Menurut Anda, di manakah logika bisnisnya?
4. Menurut Anda, folder mana yang memiliki tanggung jawab paling banyak?
5. Bisakah Anda menghapus suatu fitur tanpa menyentuh apa pun?

Bagikan apa yang Anda amati dalam sesi ini dan kami meninjaunya bersama seperti yang dilakukan seorang arsitek senior.

---

Prompt: analisis proyek Anda dengan 4 poin

Salin perintah ini dan gunakan dengan AI apa pun (ChatGPT, Claude, Copilot) yang meneruskannya ke pohon folder proyek Anda:

---

Analisis arsitektur proyek dengan menerapkan 4 poin Pilar 1 ini dan buat laporan.

POIN 1 — Struktur folder

Analisis apps/ dan libs/ dan jawab:

• Apakah pengorganisasiannya berdasarkan fitur (domain bisnis) atau berdasarkan lapisan teknis?
• Bisakah Anda menghapus seluruh fitur hanya dengan menghapus foldernya?
• Apakah fitur memiliki nama domain (checkout, catalog) atau nama teknis (list, form, detail)?
• Apakah ada folder dengan nama yang tidak jelas: utils, helpers, common, misc, data?
• Menampilkan pohon sebenarnya dari folder yang Anda temukan.

POIN 2 — Nama file dan folder

Cari seluruh proyek dan daftar:

• File dengan nama yang tidak jelas: data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils dengan layanan di dalamnya.
• Layanan dengan logika bisnis dalam shared/.
• Komponen atau layanan domain dalam core/.
• Apakah shared/ lebih berbobot dibandingkan fitur individual mana pun? Jumlah berkas.

POIN 3 — Layanan global

Cari seluruh proyek:

• Semua layanan dengan providedIn: 'root' — mencantumkan layanan mana saja dan apakah layanan tersebut harus lokal untuk suatu fitur.
• Menghitung total jumlah penyedia global.
• Mengidentifikasi layanan bisnis yang terdaftar secara global kapan layanan tersebut seharusnya ada dalam fitur Anda.
• Cari layanan di libs/services/ yang jelas-jelas milik domain tertentu.

POIN 4 — Konfigurasi global (app.config.ts atau app.module.ts)

Temukan file konfigurasi root setiap aplikasi dan analisis:

• Apa saja yang tidak boleh didaftarkan secara global?
• Apakah modul fitur dimuat dengan pemuatan lambat atau diimpor secara langsung?
• Apakah ada layanan bisnis dalam konfigurasi global?
• Berapa total penyedia yang terdaftar secara global?

FORMAT LAPORAN

Untuk setiap poin gunakan struktur yang tepat ini:

✅ Apa yang bagus

(daftar konkret dengan contoh kode nyata)

⚠️ Tanda untuk diperiksa

(daftar konkret dengan jalur file dan mengapa itu merupakan tanda)

❌ Mengatasi masalah

(daftar konkret dengan jalur file, masalah dan dampak aktual)

Pada akhirnya itu mencakup:

Ringkasan Eksekutif

Tabel dengan 4 poin, emoji status (✅ ⚠️ ❌) dan garis kesimpulan per poin.

Memprioritaskan langkah selanjutnya

Daftar maksimal 5 tindakan spesifik yang diurutkan berdasarkan dampak, dengan jalur tepat dari file atau folder yang akan disentuh.

Bersikaplah langsung. Jangan jelaskan apa itu fitur atau teori. Analisis saja proyek khusus ini dan berikan temuan nyata.