Apa arti "logika bisnis" jika bukan "semua kode pihak ketiga"?

Saya telah mendengar banyak orang berbicara tentang logika bisnis di tempat kerja, dan online, dan saya telah membaca beberapa pertanyaan di situs ini tentang hal itu, tetapi istilah itu masih tidak masuk akal bagi saya. Sebagai contoh, berikut adalah beberapa pernyataan (diparafrasekan) yang sering saya lihat:

• "Logika bisnis adalah bagian dari program Anda yang menyandikan aturan bisnis yang sebenarnya." Sebagian besar definisi yang saya baca adalah yang melingkar seperti ini.

• "Logika bisnis adalah segalanya yang unik untuk aplikasi khusus Anda." Saya tidak melihat bagaimana ini berbeda dari "aplikasi khusus Anda tidak lain adalah logika bisnis", kecuali jika kami secara tidak sengaja menemukan kembali sejumlah roda, kami dapat menggunakan perangkat lunak pihak ke-3 yang ada. Karena itulah judul pertanyaan.

• "Seharusnya ada Lapisan Logika Bisnis di atas Lapisan Akses Data Anda dan di bawah Lapisan GUI Anda." Dalam kode yang saya tulis, pengakses database harus tahu data apa yang seharusnya mereka akses, dan kode UI harus tahu banyak tentang apa yang ditampilkan untuk menampilkannya dengan benar, dan tidak ada yang benar-benar dilakukan di antaranya. dua tempat itu selain melewati gumpalan data antara klien dan server. Jadi apa yang sebenarnya seharusnya masuk ke Business Logic Layer?

• "Logika bisnis harus terpisah dari logika presentasi." Sebagian besar permintaan fitur yang kami dapatkan adalah mengubah logika presentasi untuk alasan bisnis. Jika salah satu aturan bisnis adalah untuk menampilkan harga obligasi pemerintah AS dalam notasi 32nds secara default (sambil juga menyediakan UI bagi pengguna untuk mengonfigurasinya), logika presentasi perlu setidaknya tahu aturan ini ada, jika tidak sepenuhnya menerapkannya. Selain itu, sepertinya bagian utama dari desain UX membantu pengguna memahami aturan bisnis yang coba diterapkan oleh perangkat lunak kami.

Mungkinkah saya benar-benar berada di tim yang hanya melakukan logika bisnis, dan semua logika non-bisnis dilakukan oleh tim lain? Atau apakah seluruh konsep "logika bisnis" sebagai entitas yang terpisah hanya dapat diterapkan untuk aplikasi atau arsitektur tertentu?

Untuk membantu membuat jawaban menjadi nyata: Berpura-puralah Anda harus mengimplementasikan kembali aplikasi Pizza Domino. Apa logika bisnis, dan apa logika non-bisnis dari aplikasi itu? Dan bagaimana mungkin untuk menempatkan logika bisnis pemesanan pizza dalam "lapisan" kode sendiri, tanpa sebagian besar informasi pizza berdarah ke dalam akses data dan lapisan presentasi?

Pembaruan: Saya sampai pada kesimpulan bahwa tim saya mungkin melakukan 90% kode UI dan sebagian besar - tetapi tidak semua - dari apa yang Anda sebut logika bisnis berasal dari tim atau perusahaan lain. Pada dasarnya, aplikasi kami adalah untuk pemantauandata keuangan, dan hampir semua fitur adalah cara bagi pengguna untuk menyesuaikan data apa yang mereka lihat dan bagaimana mereka melihatnya. Tidak ada pembelian atau penjualan yang terjadi (meskipun kami sedikit mengintegrasikan dengan aplikasi lain dari perusahaan kami yang melakukan itu), dan data aktual dipasok oleh banyak sumber eksternal. Namun kami mengizinkan pengguna untuk melakukan hal-hal seperti mengirim salinan "monitor" mereka ke pengguna lain, jadi detail cara kami menangani hal itu mungkin memenuhi syarat sebagai logika bisnis. Sebenarnya ada aplikasi seluler yang saat ini berbicara dengan beberapa kode backend kami, dan saya tahu persis apa bagian dari kode frontend kami yang saya inginkan untuk dibagikan dengan UI kami di dunia yang ideal (pada dasarnya M dalam kuasi-MVC kami) jadi Saya kira itulah BLL untuk kita.

Saya menerima jawaban user61852 karena itu memberi saya pemahaman yang jauh lebih konkret tentang apa yang "merujuk" logika bisnis dan tidak mengacu.

Saya akan memberi Anda beberapa tips mengenai aplikasi CRUD , karena saya tidak punya banyak pengalaman dalam game atau aplikasi yang intensif secara grafis:

• Logika bisnis biasanya melibatkan aturan yang telah dipelajari atau diputuskan oleh pemilik bisnis selama bertahun-tahun beroperasi, seperti misalnya: "tolak kredit baru jika klien belum selesai membayar yang terakhir" , atau "kami tidak menjual sarapan lewat jam 11 pagi " , atau " Senin dan Selasa, pelanggan dapat membeli dua pizza dengan harga satu " .
• Tentu saja lapisan presentasi harus menunjukkan pesan yang menunjukkan ketersediaan diskon, atau alasan kredit ditolak, tetapi lapisan tersebut tidak memutuskan hal-hal itu, itu hanya mengkomunikasikan kepada pengguna sesuatu yang terjadi di bawah tenda.
• Logika bisnis biasanya melibatkan alur kerja , misalnya: "item ini harus disetujui dalam waktu 3 hari kerja oleh beberapa manajer atau dimasukkan ke dalam tahap 'permintaan informasi', jika pelanggan belum mengirimkan dokumen yang diperlukan, maka item tersebut ditolak" .
• Lapisan presentasi biasanya tidak berurusan dengan alur kerja semacam itu, itu hanya mencerminkan keadaan alur kerja.
• Selain itu, lapisan akses data biasanya mudah, karena keputusan telah dibuat oleh logika bisnis. Lapisan ini terpengaruh ketika Anda memutuskan untuk memigrasikan data Anda dari MS SQL Server ke Oracle, misalnya
• Memang benar kadang-kadang GUI melakukan beberapa validasi untuk menghindari panggilan ke server, tetapi itu adalah sesuatu yang harus dilakukan secara bijaksana atau Anda bisa memiliki banyak logika bisnis di lapisan itu.
• Sebagian besar kebingungan Anda mungkin timbul dari kenyataan bahwa dalam aplikasi Anda tidak ada pemisahan kekhawatiran dan secara efektif Anda memiliki terlalu banyak logika bisnis di lapisan presentasi. Fakta bahwa Anda (secara keliru) memiliki logika bisnis di lapisan aplikasi atau lapisan akses data Anda tidak mengubah fakta bahwa itu adalah logika bisnis.
• Hal-hal seperti menampilkan jarak dalam sistem metrik alih-alih mil / yard / kaki bukan logika presentasi, itu logika bisnis . Lapisan bisnis harus mengembalikan data dalam unit yang diperlukan dan memberi tahu lapisan presentasi unit apa yang ditanganinya untuk menunjukkan label yang sesuai, tetapi ini jelas merupakan masalah logika bisnis.
• Logika bisnis tidak boleh terpengaruh kenyataan bahwa Anda menggunakan Oracle sekarang, bukan Postgres, atau oleh kenyataan bahwa perusahaan mengubah logo atau style sheet-nya.
• Ada aturan bisnis apakah Anda mengotomatiskannya atau tidak dengan menulis aplikasi . Mereka dapat ditegakkan bahkan ketika bisnis menggunakan solusi berteknologi rendah seperti pena dan kertas.
• Jika Anda memiliki versi seluler aplikasi desktop Anda, atau versi web , masing-masing versi tersebut memiliki lapisan presentasi yang berbeda , tetapi (semoga) lapisan bisnis yang sama.

Sepertinya sebagian besar pekerjaan Anda ada di lapisan UI. Mengubah format tampilan untuk alasan bisnis, tidak menyiratkan logika bisnis apa pun. Perubahan adalah perubahan pada logika tampilan.

Mampu mengubah format menyiratkan beberapa logika bisnis yang mungkin melibatkan kegigihan preferensi.

Mempertahankan format cookie, juga bisa diterapkan di lapisan tampilan.

Namun, ini bisa diimplementasikan dengan cara MVC. (Beberapa model menerapkan tampilan sebagai MVC-nya sendiri yang mampu menangani preferensi.)

• Preferensi pengguna dapat disimpan oleh model (database / cookie).
• Pengontrol akan bereaksi terhadap memformat permintaan dengan mengubah preferensi pengguna dalam model.
• Tampilan akan menyesuaikan dengan preferensi pengguna. Preferensi dapat diminta dari model, atau disediakan oleh pengontrol.

Membuat tebakan cerdas tentang aplikasi Anda.

• Ada model yang berisi obligasi yang tersedia, dan harga data untuk mereka.
• Ada pandangan yang memungkinkan pengguna untuk melihat berbagai hal yang dapat mereka lakukan: mencari obligasi, menampilkan harga, membandingkan hasil, menerima pesanan, dan yang menampilkan hasil yang dikembalikan oleh model bisnis dalam menanggapi permintaan.

• Logika bisnis menangani hal-hal seperti:

  • Melakukan pencarian dan menyediakan tampilan untuk ditampilkan.
  • Menemukan harga untuk obligasi dan menyediakan tampilan untuk ditampilkan.
  • Membandingkan hasil dan menyediakan data untuk tampilan untuk ditampilkan.
  • Memproses pesanan dan menyimpannya dalam model.

Jika ini dilakukan dengan benar, seharusnya memungkinkan untuk menyediakan beberapa komponen tampilan tanpa mengubah model atau logika bisnis. Misalnya, jika desain saat ini adalah situs web, server tampilan baru untuk aplikasi iPhone atau Android akan menggunakan model dan logika bisnis yang ada. Ini mungkin memperkenalkan fungsionalitas bisnis baru untuk memberikan pemberitahuan push ketika pesanan dipenuhi, yang mungkin memerlukan perubahan ke beberapa lapisan.

Rincian ini memungkinkan pemisahan masalah.

• Lapisan data yang diwakili oleh model cenderung relatif stabil.
• Lapisan bisnis adalah tempat keputusan bisnis diterapkan: Apakah / dapatkah permintaan itu dipenuhi? Apakah semua data yang diperlukan telah diperoleh? Apakah pengguna diotorisasi? Apakah ada tanda bahaya pada transaksi?
• Lapisan tampilan cenderung kurang stabil, dan mungkin ada lebih dari satu. Di sinilah tampilan dan nuansa aplikasi berada. Dimungkinkan untuk mengupas ulang aplikasi secara menyeluruh, tanpa mengubah lapisan lainnya.