Apa sebenarnya "logika bisnis" itu?


115

Saya bekerja dengan pengembangan web sejak 2009, ketika saya mulai dengan PHP. Ketika saya pindah ke ASP.NET saya telah mendengar banyak tentang DDD dan OOAD di mana banyak fokus diberikan kepada "logika bisnis" dan "aturan bisnis" ini. Intinya adalah bahwa semua aplikasi yang saya kembangkan sampai sekarang semuanya tentang operasi CRUD dan saya belum pernah melihat hal-hal ini dalam praktek.

Saya benar-benar tidak dapat membayangkan hal-hal apa yang sebenarnya dapat dipraktikkan. Jadi, apa sebenarnya logika bisnis ini dan bagaimana ini cocok dengan suatu aplikasi? Saya tahu ini diimplementasikan sebagai metode dalam model domain, tetapi apa metode yang mungkin bisa, dan di mana dalam aplikasi mereka bisa digunakan?

Jawaban:


107

CRUD adalah akronim yang merupakan singkatan dari Buat, Baca, Perbarui dan Hapus. Itu adalah empat operasi dasar yang dapat Anda lakukan pada tuple basis data. Tetapi selalu ada lebih banyak aplikasi bisnis daripada membuat, membaca, memperbarui, dan menghapus catatan basis data.

Mari kita mulai dengan beberapa definisi dasar, dan kemudian melihat beberapa contoh dan melihat bagaimana definisi tersebut memetakan ke contoh, dan bagaimana mereka memetakan ke perangkat lunak yang sebenarnya.

Logika bisnis atau logika domain adalah bagian dari program yang menyandikan aturan bisnis dunia nyata yang menentukan bagaimana data dapat dibuat, disimpan, dan diubah. Ini menentukan bagaimana objek bisnis berinteraksi satu sama lain, dan menegakkan rute dan metode yang digunakan untuk mengakses dan memperbarui objek bisnis.

Aturan Bisnis menggambarkan operasi, definisi, dan kendala yang berlaku untuk organisasi. Operasi secara kolektif membentuk suatu proses; setiap bisnis menggunakan proses ini untuk membentuk sistem yang menyelesaikan sesuatu.

Sekarang, mari kita bekerja dengan beberapa contoh.

Mentransfer uang dari satu rekening giro ke yang lain

Pertama, hal-hal apa saja yang perlu Anda ketahui (input)?

  • Identitas orang yang melakukan transfer
  • Jumlah uang yang akan ditransfer
  • Sumber memeriksa nomor akun
  • Target memeriksa nomor akun

Apa saja "aturan bisnis" yang harus diterapkan?

  • Orang yang mengajukan permintaan harus memiliki wewenang untuk melakukannya.
  • Transaksi harus bersifat atomik .
  • Transaksi dapat memiliki persyaratan pelaporan kepada pemerintah, jika melebihi jumlah tertentu

Dengan "atomik," maksud saya bahwa transaksi harus benar-benar berhasil atau gagal total. Anda tidak dapat memiliki transaksi akun di mana uang dikeluarkan dari satu akun tanpa tiba di akun lain (uang hilang), atau uang disetorkan ke akun, tetapi tidak didebit dari akun lain (uang muncul secara ajaib entah dari mana).

Memesan sesuatu dari Amazon.

Apa yang perlu kamu ketahui?

  • Identitas orang yang memesan
  • Pengiriman Informasi
  • Informasi tagihan
  • Metode pembayaran
  • Jumlah dan kuantitas setiap barang yang akan dikirim
  • Cara mengirim (bermalam, kapal lambat atau super saver)
  • Tarif Pajak Negara

Apa yang terjadi setelah pesanan dilakukan?

  • Barang ditarik dari stok
  • Jumlah tangan didebit
  • Barang dikemas untuk pengiriman
  • Stok barang habis dipesan-tunggak
  • Barang-barang yang jatuh di bawah jumlah minimum dipesan
  • Satu atau dua pengiriman?
  • Daftar faktur / pengiriman dicetak, dan ditempatkan dengan pesanan

    ..etc


5
Saya suka definisi tetapi dalam contoh, saya kehilangan perbedaan yang Anda buat antara logika bisnis versus aturan bisnis.
jdv-Jan de Vaan

1
BAIK. Tetapi mengapa Anda memberi label "Transaksi harus bersifat atomik" sebagai aturan bisnis? Saya terdengar agak level rendah untuk aturan bisnis.
jdv-Jan de Vaan

9
@ jdv: Anda terlalu memikirkan ini. Apakah teller hanya melakukan setengah dari transaksi itu?
Robert Harvey

1
@jdv: Mengatakan bahwa transaksi tersebut harus atomik menyiratkan dua hal: (1) jika ada sesuatu yang mengganggu pemrosesan transaksi, dimungkinkan untuk membatalkan setiap efek transaksi seolah-olah itu tidak pernah terjadi (kecuali, mungkin, untuk pembuatan laporan kesalahan-log), atau lengkapi semua yang perlu dilakukan; (2) tidak ada bagian dari transaksi yang akan tumpang tindih dengan transaksi "atom" lainnya yang melibatkan akun tersebut. Misalnya, jika seseorang yang memiliki $ 1.000.000 di masing-masing dari dua akun mentransfer $ 500.000 dari satu ke yang lain pada saat bank diminta ...
supercat

4
Transaksi @jdv menjadi atom adalah persyaratan mendasar yang perlu dipastikan dan terkait dengan keadaan akhir.
icarus74

27

CRUD hanyalah Buat, Baca, Perbarui, Hapus bahwa aplikasi tidak.

Sampai batas tertentu, pelacak bug juga merupakan aplikasi CRUD. Buat bug, Baca (tampilkan) bug, Perbarui bug, dan mungkin, hapus bug.

Namun, ada lebih banyak pelacak bug dari sekadar CRUD.

  • Pengembang tidak diizinkan menandai bug yang diverifikasi atau ditutup - itu bagian dari pekerjaan QA. Dan ada beberapa kode di sana untuk memastikan bahwa seseorang yang tidak memiliki peran QA tidak dapat menandai bug sebagai ditutup atau diverifikasi.
  • Tidak seorang pun kecuali manajer proyek yang benar-benar dapat menghapus bug.
  • Agar bug ditandai sebagai "tes saya", harus ada setidaknya satu komit kode terhadap bug.
  • Hanya bug yang dalam status 'tertutup' yang dapat dipindahkan ke status 'buka kembali'
  • Pengembang yang ditugaskan untuk bug tidak dapat memindahkannya dari 'review kode' ke 'review kode selesai'
  • QA dan Pengembang hanya dapat melihat bug pada proyek tempat mereka ditugaskan.

Kode yang mengimplementasikan di atas adalah logika bisnis aplikasi.

Pembatasan alur kerja, atau siapa yang dapat melakukan berbagai operasi di CRUD. Inilah yang memisahkan satu aplikasi CRUD dari yang lain. Mereka adalah bagian di mana Anda perlu mendapatkan bisnis untuk benar-benar mengatakan cara kerja aplikasi. Betapa logisnya ... well, sebaiknya didiskusikan sambil minum bir di luar jangkauan manajer proyek. Tapi itulah logika bisnis.

Tentu, mungkin untuk menulis aplikasi CRUD 'murni' di mana tidak ada peran, semuanya dapat dimodifikasi dan dilihat - tetapi ini adalah pengecualian daripada aturan.

Logika bisnis adalah logika yang Anda tulis ke dalam program Anda untuk menangani aturan bisnis yang Anda berikan.


Ketika Anda mulai masuk ke aturan bisnis, ini cenderung berada pada tingkat yang lebih tinggi daripada kasar itu sendiri atau logika bisnis. Ini cenderung menjadi hal yang Anda dapatkan dari analis bisnis yang bekerja dengan bisnis tersebut.

Pertimbangkan dalam contoh ini, program yang menentukan bagaimana menangani pengembalian suatu barang di meja pengembalian di toko.

  • Jika tanda terima sama dengan atau lebih dari 90 hari, hanya kredit toko yang dapat diberikan
  • Jika kwitansi kurang dari 90 hari, kreditkan kwitansi yang digunakan kwitansi pembelian (kredit dikembalikan pada kartu kredit, uang tunai kembali ke uang tunai, kredit toko masuk ke kredit toko) ... kecuali adalah cek, dalam hal ini menggunakan uang tunai.

Itulah beberapa aturan bisnis. Mereka tidak berbicara dengan bagian CRUD dari aplikasi.

Saat bekerja dengan aturan bisnis, Anda mungkin sering menemukan ini ditulis dalam mesin aturan (misalnya, Windows Workflow Foundation Rules Engine ) alih-alih menulis kode mentah di sistem Anda.


Sadarilah bahwa perbedaan logika / aturan adalah salah satu terminologi dan dapat diperdebatkan sepanjang malam (lebih dari satu gelas bir lagi). Meskipun ini bukan perbedaan yang tidak biasa, meskipun keduanya dapat berbaur satu sama lain.


23

Jawaban lain benar. Satu pemikiran tambahan ...

Logika Bisnis Portable

Jika Anda mengimplementasikan ulang proyek perangkat lunak dalam bahasa pemrograman yang berbeda, katakanlah pindah dari Turbo Pascal ke Java , logika bisnis & aturan bisnis adalah kesamaan dari proyek lama dan baru .

Bahasa pemrograman akan berbeda. The source code akan sama sekali berbeda. Alat-alat ( IDE , kompiler , dan semacamnya) mungkin sama sekali berbeda. The antarmuka pengguna mungkin sepenuhnya re-organisasi atau memiliki yang berbeda tampilan dan nuansa . The dokumentasi mungkin akan berbeda. Tetapi tujuan kedua proyek, hasil akhir pekerjaan yang dilakukan / tujuan yang dicapai, akan sama.


10

Logika bisnis pada dasarnya terdiri dari 2 kategori besar: validasi dan aliran. Logika bisnis mengatakan bahwa qty 1 harus lebih besar dari atau sama dengan qty 2 - misalnya, jumlah barang yang harus dibeli harus kurang dari atau sama dengan jumlah item dalam persediaan.

Dalam satu aplikasi, pelaku bisnis akan mengatakan ini adalah aturan bisnis, dan Anda menulis kode untuk menegakkan logika bisnis ini (validasi). Aplikasi lain akan mengatakan bahwa jika jumlah item yang dipesan lebih besar dari jumlah item yang ada dalam stok, untuk menerima pesanan dan kemudian menempatkan pesanan Anda sendiri untuk perbedaan ditambah 20%, dan Anda akan menulis logika bisnis ini (flow) .

CRUD hanya mendapatkan data masuk dan keluar penyimpanan dan mengubahnya. Logika bisnis menentukan apa yang Anda lakukan dengan data itu dan transformasi apa yang diizinkan untuk dilakukan. Apakah pelanggan Anda lahir di masa depan, di bawah 5 tahun, dari wilayah geografis tertentu (diskon untuk penduduk lokal / pengunjung). CRUD sederhana, mengetahui bahwa Anda bisa mendapatkan kredit pajak anak hanya jika anak itu tinggal bersama Anda selama lebih dari separuh waktu itu hidup di tahun kalender BUKAN lebih dari 6 bulan, lebih kompleks.


9

Logika atau aturan bisnis adalah segala sesuatu yang tidak berkaitan dengan mekanisme antarmuka pengguna ("hal-hal pemrograman"). Itu adalah hal-hal yang masih harus Anda terapkan jika Anda melakukan transaksi ini atau apa pun 100 tahun yang lalu (secara manual). Misalnya, kapan harus menerapkan pajak penjualan untuk pembelian.


1

"Logika bisnis" dari suatu program atau aplikasi adalah bagian dari kode yang benar-benar melakukan sesuatu dengan input (dari pengguna, sistem operasi, dan lain-lain). "Aturan bisnis" suatu aplikasi biasanya merupakan parameter yang ditentukan dari program itu sendiri (seperti bagaimana menangani input). Paling tidak, inilah yang saya dengar dari banyak orang. Mereka cukup mirip istilah untuk menggambarkan bagian-bagian kode.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.