Struktur kode untuk menangani banyak pasar? (aturan bisnis yang berbeda untuk setiap negara bagian di AS)

8

Kami sedang mengembangkan aplikasi yang memiliki persyaratan yang sedikit berbeda untuk setiap pasar bisnis (negara dan negara bagian) tempat aplikasi itu tersedia. Sepertinya ini adalah situasi yang umum tetapi saya tidak dapat menemukan artikel yang bagus tentang penataan kode / modul untuk skenario ini.
Ini adalah aplikasi C # dan kami berdebat antara strategi vs pola Templat tetapi ada juga pertimbangan struktur folder dan konvensi penamaan. Sepertinya proyek terpisah untuk setiap negara bagian akan menjadi tidak terkelola dengan cepat (mis. 5 layanan inti X 50 proyek khusus negara) = 250 proyek !!) Mungkin 1 proyek kustom per layanan yang menangani spesialisasi yang diatur dalam sub-folder per negara?

c# design-patterns architecture architectural-patterns

— Kim
sumber

Bisakah Anda menambahkan lebih spesifik tentang apa yang sebenarnya berbeda antar negara?

— paj28

8

Miliki satu aplikasi dan rancang solusi konfigurasi yang sesuai.

JacquesB mengisyaratkan ini, tapi saya ingin menyatakannya lebih kuat. Anda harus melakukan ini dengan konfigurasi daripada mengembangkan 50+ versi basis kode. Apa pun akan menjadi tidak terkendali.

Jika ada persyaratan kompleks yang tidak dapat ditangani oleh parameter konfigurasi sederhana, rancang solusi konfigurasi yang lebih kompleks.

Konfigurasi Anda bahkan mungkin memiliki bahasa skrip sederhana yang mendefinisikan persyaratan logika. Itu tidak apa-apa. Kuncinya adalah bahwa "konfigurasi" harus dipisahkan dengan bersih dari basis kode aplikasi.

Kalau tidak, hal-hal seperti mengidentifikasi dan memperbaiki bug akan berantakan. Dengan versi normal selain versi khusus lokal, Anda akan memiliki ratusan versi di bidang ini. Dan Anda tidak akan dapat dengan mudah mengetahui apakah bug terkait dengan kode spesifik lokal atau kode dasar.

Mulailah berpikir tentang kasus tepi sekarang.

Ini adalah situasi di mana ada risiko tinggi untuk membuat asumsi buruk yang akan sangat mahal. Seperti "Setiap pengguna aplikasi hanya perlu beroperasi dalam satu lokal." Benarkah? Pastikan Anda berpikir sangat keras tentang masalah tersebut sedini mungkin.

Kami sedang menyiapkan solusi konfigurasi menggunakan AutoFac Multitenancy. Adakah saran untuk mengatur dan memberi nama komponen (kelas / proyek)?

— Kim

Iya. Saya akan berkomentar bahwa ini adalah contoh yang bagus untuk injeksi Ketergantungan. Anda dapat mendefinisikan antarmuka umum dan membuat komponen spesifik yang kemudian diteruskan per beberapa konfigurasi. ini harus memungkinkan testabilitas dan perawatan yang jauh lebih baik daripada skrip kustom seperti yang disebutkan dalam jawaban lain.

— Fran

6

Itu benar-benar tergantung pada apa yang berbeda. Apakah ini sesuatu yang dapat diekspresikan murni oleh konfigurasi (mis. Tarif pajak), atau apakah Anda benar-benar memerlukan logika kode terpisah untuk setiap negara? Semakin banyak yang dapat Anda tangani murni dengan konfigurasi, semakin baik!

Anda kemungkinan besar tidak perlu kode yang terpisah oleh negara. Misalnya Anda menyebutkan bahwa beberapa pasar mengeluarkan pengembalian uang sementara masalah lainnya menggantikan. Ini masih hanya dua jalur kode yang perlu Anda uji. Kemudian Anda dapat memiliki konfigurasi yang menunjukkan jalur mana yang harus digunakan untuk negara bagian mana. Ini jauh lebih baik daripada memiliki kode terpisah untuk setiap negara bagian. Anda masih hanya perlu menguji dua jalur kode rater dari 50.

Jika Anda pernah merasa perlu untuk menulis kode individual untuk masing-masing dari 50 negara, Anda mungkin salah melakukannya. Anda seharusnya tidak memiliki proyek terpisah per negara, atau bahkan memiliki "50 berbeda" dari apa pun kecuali bagian konfigurasi.

— JacquesB
sumber

ini lebih dari sekadar perpajakan tetapi tingkat perbedaannya tidak diketahui saat ini. Kami juga berurusan dengan banyak negara. Alur kerja di sana juga bisa sedikit berbeda seperti beberapa pasar mengembalikan pembelian sementara yang lain mengeluarkan penggantian. Dan tentu harga berbeda per pasar.

— Kim

Apa yang diterima JacquesB adalah abstraksi. TKI, bagaimana mungkin hal-hal yang terlihat berbeda sebenarnya sama? "Semua negara bagian mengenakan pajak" Sekarang saya memiliki konsep umum yang dapat saya enkode secara universal: "CalcTax ()". Dan yang Anda butuhkan hanyalah tarif pajak khusus (tabel pajak) - yaitu konfigurasi. Dengarkan saya sekarang dan percayalah nanti, "data konfigurasi" - konsep abstrak! - akan sangat menyederhanakan kode.

— radarbob

Jika ada banyak fungsi yang tumpang tindih di antara negara-negara (di luar opsi "default" yang efektif), ini adalah saran yang bagus. Jika negara rentan terhadap nuansa yang membuatnya sulit / berbahaya untuk menyatukannya sebagai semacam "Opsi B", itu bukan. OP perlu memikirkannya. Ada juga bahaya sakit kepala jika satu negara mengeluarkan undang-undang baru yang memaksa pembaruan kode, tetapi itu akan berlaku untuk semua kondisi di mana banyak negara menggunakan kode yang sama.

— BlairHippo

5

Saya sudah memiliki pengalaman praktis dengan proyek-proyek seperti itu, dan setidaknya dapat menawarkan beberapa pedoman umum.

JacquesB benar bahwa konfigurasi adalah teman terbaik Anda. Apakah Anda meletakkan konfigurasi dalam file atau dalam tabel database adalah pilihan gaya (meskipun saya akan condong ke file konfigurasi, karena begitu Anda mendapatkan layanan yang diatur, saya berani bertaruh itu tidak akan banyak berubah).
Harapkan kode yang terlihat jauh lebih tidak langsung daripada apa yang mungkin Anda terbiasa. Akan ada banyak tempat di mana alih-alih mengatakan "Lakukan ini selanjutnya," Anda akan mengatakan "Tanyakan konfigurasi apa yang harus kita lakukan selanjutnya, lalu lakukan itu". Yang bisa menjadi sakit kepala karena perkembangan, tetapi Anda akan terbiasa.
Saya akan merekomendasikan struktur "Ini adalah elemen umum yang mungkin semua orang inginkan, dan ini adalah elemen dipesan lebih dahulu yang dirancang tangan untuk keadaan individu." Untuk itu, mengidentifikasi dengan benar bahwa fungsionalitas default akan menjadi bagian besar dari seberapa mudah / buruk kode ini untuk bekerja dengan di masa depan. Bersiaplah untuk melakukan beberapa refactoring ketika Anda mengetahui bahwa lebih banyak barang yang menurut Anda perlu dikonfigurasi.
Selalu pastikan bahwa setiap pesan kesalahan yang berasal dari elemen khusus mengidentifikasi dengan tepat dari mana mereka berasal. Banyaknya jalur eksekusi yang berbeda berarti bahwa debugging akan menyedot apa pun yang terjadi; apa pun yang dapat Anda lakukan untuk mengurangi jumlah berburu telur paskah akan lebih bermanfaat.
Investasikan waktu untuk membuat test suite otomatis yang bagus. Rangkaian pengujian otomatis yang benar-benar bagus. Ini selalu merupakan praktik yang baik, tetapi bagi Anda, itu bisa berarti perbedaan antara keberhasilan dan kegagalan. Sekali lagi, ini adalah beragam jalur eksekusi; setiap modifikasi pada kode umum akan membuat Anda rentan terhadap bug efek kupu-kupu di cabang yang tidak Anda harapkan. Anda harus menangkap bug itu sebelum mencapai produksi.

— BlairHippo
sumber

Terima kasih. Adakah saran untuk memberi nama kelas, mengelompokkan proyek? Haruskah implementasinya diakhiri dengan nama pasar atau mencoba untuk menggambarkan fungsi yang berbeda?

— Kim

Saya bukan orang biasa, jadi saya tidak dapat berbicara secara spesifik tentang bagaimana Anda memberi nama kelas. Tapi jujur, saya pikir Anda ingin nama paket yang menggabungkan fungsi pasar DAN, sehingga Anda dapat mengetahui apa yang seharusnya dilakukan. Sesuatu seperti ourproject.calculations.taxuntuk default dan ourproject.florida.calculations.taxuntuk mod kustom apa pun yang dipaksakan oleh hukum Florida kepada Anda (jika ada). Di mana Anda menempatkan nama pasar adalah titik diskusi, tetapi saya akan cenderung membuatnya mudah untuk melihat penyesuaian apa yang dipaksakan oleh pasar tertentu pada Anda.

— BlairHippo

2

Meskipun config dapat membantu itu tidak akan menyelesaikan semua masalah Anda dan itu dapat membuat yang baru.

Sejauh ini cara terbaik dalam pengalaman saya adalah menciptakan solusi multi tenancy yang dapat menangani semua atau beberapa negara (penyewa)

Ini membutuhkan konfigurasi. yaitu persentase pajak penjualan menurut negara tetapi juga kode kondisional LegalMethodOfKalkulasiPekerjaanHoursA vs B

Jika aplikasi Anda di-host / online, Anda dapat mengambil pendekatan layanan mikro pada kode kondisional tetapi solusi off-line harus mengikat semua modul opsional dan memilih di antara mereka

Anda akan menemukan beberapa modul digunakan kembali di semua negara, seperti pajak penjualan dan beberapa yang gila hukum hanya digunakan di satu negara. Anda juga akan menemukan bahwa hukum berubah seiring waktu. jadi modul yang digunakan akan bervariasi berdasarkan waktu dalam satu negara

Jadi saya akan memilih penamaan berdasarkan fungsi alih-alih negara.

— Ewan
sumber

Saya suka ini - kode cabang berdasarkan fungsi, misalnya "harus bertanya alamat" "pengiriman bebas pajak". Kemudian konfigurasi untuk itu memetakan setiap negara bagian ke satu set fungsi.

— paj28