Haruskah saya mengatur folder saya dengan domain bisnis atau domain teknis?

Misalnya, jika saya menggunakan arsitektur mirip MVC, struktur folder mana yang harus saya gunakan:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

Atau:

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

Saya sengaja meninggalkan ekstensi file untuk menjaga bahasa agnostik pertanyaan ini.

Secara pribadi, saya lebih suka memisahkan berdasarkan domain bisnis (firasat), tapi saya melihat bahwa sebagian besar kerangka kerja terpisah oleh domain teknis. Mengapa saya memilih satu dari yang lain?

Saya pikir ini tergantung pada proyek tertentu.

Misalnya, jika domain bisnis yang berbeda benar-benar independen satu sama lain, maka saya akan mengatur berdasarkan domain bisnis.

Tetapi jika ada kode bersama antara domain bisnis, atau lebih tepatnya, domain bisnis adalah varian berbeda dari basis kode yang sama, maka tampaknya lebih logis untuk mengatur dengan domain teknis. Dan jika Anda menggunakan segala jenis bahasa yang Berorientasi Objek, maka Anda mungkin dapat subkelas pengendali generik Anda, model, dll dalam file khusus bisnis Anda untuk membuatnya lebih tipis.

Ada juga (emas) jalan tengah di antara keduanya - menghapus kode bersama ke domain itu sendiri dan menggunakannya di domain lain. Ini memberi Anda layout bertenaga perasaan, tetapi memungkinkan kode bersama antara domain bisnis.

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

PS. Saya pikir sebagian besar kerangka kerja diatur oleh domain teknis hanya karena mereka cenderung berharap bahwa Anda menggabungkan domain bisnis yang berbeda menjadi satu proyek hanya jika Anda memiliki kode bersama dan sebaliknya akan membuat proyek terpisah.

EDIT:

Misalnya, ada aplikasi web yang menangani gudang perusahaan. Dalam bentuk umum ini mungkin berlaku untuk banyak perusahaan, tetapi masing-masing dari mereka mungkin memiliki beberapa spesifik yang tidak terpenuhi dan melarang mereka untuk membeli. Misalnya salah satu dari mereka telah menggunakan tablet untuk forklift dan membutuhkan Tampilan khusus untuk mereka sementara yang lain ingin untuk mengatur item menjadi tiga level, bukan default dua.

Anda tentu saja dapat membayar proyek untuk masing-masing perusahaan ini. Tetapi jika kerangka / bahasa memungkinkan, Anda bisa menggunakan subclassing atau plugins dll untuk menyesuaikan sedikit demi sedikit proyek generik dengan kebutuhan setiap pelanggan dan mengaturnya dalam tata letak Domain Bisnis.

Misalnya, jika proyek generik mengekspor ke JSON hanya Item itu sendiri, Domain1 dapat subkelas controller dan membuatnya mengekspor juga masalah pengiriman baru-baru ini.

Dan jika nanti Anda menemukan bahwa Domain1 memiliki komponen yang juga valid untuk Domain2, Anda bisa mengekstrak versi generiknya ke Shared.

Seperti yang Anda katakan, banyak kerangka kerja diatur oleh domain teknis dan itulah yang saya gunakan untuk saat ini, hanya karena FW pilihan saya menjadikan ini lebih mudah. Tetapi dengan sedikit (atau banyak) minyak siku, saya pikir saya dapat menulis ulang jalur sertakan untuk mendukung tata letak Domain Bisnis juga.

Saya pikir sangat mencerahkan untuk bertanya, "apa yang lebih cenderung saya tambahkan secara teratur, lebih banyak domain, atau lebih banyak divisi teknis?" Lalu apa pun jawabannya, letakkan itu di tingkat atas.

Dalam kebanyakan kasus, arsitektur teknis Anda akan memadat lebih cepat dari domain Anda. Itu berarti Anda harus mengatur berdasarkan domain terlebih dahulu, kemudian oleh komponen arsitektur. Alasannya adalah bahwa ketika sesuatu dalam suatu domain berubah, Anda mungkin harus menambahkan atau mengubah beberapa komponen teknis dalam domain itu, tetapi mudah-mudahan itu terlokalisasi dan tidak banyak menyebar ke domain lain.

Jika Anda mengubah kerangka kerja GUI Anda, maka itu berarti perubahan Anda akan tumpah di seluruh aplikasi, tetapi sekali lagi, Anda jarang mengubah kerangka GUI Anda, tetapi Anda selalu mengubah logika domain Anda.

Menyatukan segala sesuatu jika mereka cenderung berubah pada saat yang sama.

Ada alternatif lain dan itu adalah memindahkan bagian-bagian terpisah dalam plugin. CakePHP melakukan itu misalnya. Ini akan memungkinkan Anda untuk menghasilkan bagian-bagian MVC lengkap yang dapat digunakan kembali yang dapat Anda urutkan berdasarkan logika apa pun yang Anda inginkan.

Aplikasi utama Anda hanya akan menggunakannya dan menautkannya.

Pada dasarnya pertanyaan Anda juga tentang kohesi dan penggandengan. Anda ingin bagian-bagian yang terpisah bekerja secara independen. Dengan begitu Anda mendapatkan kode yang dapat diuji dan digunakan kembali.

Mempertimbangkan hal itu: Jika Anda membagi berdasarkan domain, bagaimana Anda akan menggunakan kembali bagian dari aplikasi Anda? Misalnya mengambil webshop: permintaan masuk untuk / pesanan / tampilan / 1 sehingga Anda harus menunjukkan pesanan nr. 1. Pergi ke / order / controllers / order_controller Jika Anda memisahkan domain dengan produk dan pesanan Anda sudah membutuhkan bagian dari "domain" lainnya.

Di sana Anda dapat mulai menghubungkan hal-hal tetapi kemungkinan hal-hal di sebagian besar bisnis terlalu kohesif. Jika Anda mengambil pendekatan teknis. Misalnya, Anda dapat meminta plugin menangani pesanan. Anda memasukkan objek Produk ke dalamnya dari aplikasi pusat Anda. Dengan begitu Anda dapat menguji plugin dengan mudah, cukup buat beberapa objek Produk dengan nama dan harga dan kirimkan.

Plugin akan melakukan apa yang perlu dilakukan. Ini akan tergantung pada inputnya dan bukan pada "bagian / domain / area" lainnya.

Microsoft ASP.Net MVC 3 memiliki konsep "Area". Ketika Anda memperkenalkan "Area" ke dalam proyek MVC Anda, mereka memecahnya seperti:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Saya menemukan ini sangat alami. Suatu area adalah "bagian besar" dari sebuah proyek, dan bekerja di unit mandiri hanya membuat banyak akal.

Kami menggunakan ruang nama untuk mencocokkan, FWIW.

Dari pengalaman pribadi saya dengan toko web yang terdiri dari 300.000 baris kode, saya akan selalu pergi untuk mengatur berdasarkan domain bisnis. Dengan cara ini, Anda tidak hanya bisa mendapatkan gambaran umum singkat dari semua kelas yang relevan ketika Anda bekerja pada satu area fungsional, di Jawa Anda juga dapat menggunakan visibilitas paket.

Beberapa detail untuk mereka yang tertarik: Ketika proyek dimulai 5 tahun yang lalu, para pengembang membuat struktur paket berikut:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Setiap fungsi toko seperti keranjang belanja, pencarian produk, dll. Terdiri dari beberapa tindakan, masing-masing dengan kelas bentuknya sendiri (struktur diamanatkan oleh kerangka kerja MVC). Apa yang akhirnya kami dapatkan adalah lebih dari 200 kelas dalam paket tindakan, masing-masing terpisah sepenuhnya dari kelas bentuk yang terkait. Yang lebih buruk adalah bahwa tindakan tidak menerapkan terlalu banyak logika, tetapi memanggil layanan khusus fungsi yang berada di paket lain.

Saya menyarankan dan meyakinkan tim bahwa kita harus beralih ke mengatur paket berdasarkan domain bisnis. Alasannya sederhana: jika Anda benar-benar ingin melihat daftar semua tindakan, Anda cukup membuka tampilan hierarki jenis IDE yang layak. Namun, yang tidak dapat dilakukan oleh IDE adalah menyimpulkan domain bisnis yang dimiliki kelas. Selain itu, pendekatan itu memungkinkan Anda untuk membuat hanya kelas-kelas yang publik yang dibutuhkan oleh beberapa fungsi, menjaga sisanya pada visibilitas paket.

Saya setuju bahwa banyak kerangka kerja terpisah oleh domain teknis dan karenanya saya sering memulai dengan cara ini ketika menggunakan kerangka kerja baru. Namun, saya secara konsisten memutuskan untuk menggunakan domain bisnis sebagai level utama organisasi folder.

Secara pribadi, saya pikir akan lebih mudah untuk menyimpan Foo Controller dan Foo Repository saya atau apa pun bersama-sama daripada bolak-balik antara folder Controller's dan folder Repository karena saya sering harus bekerja pada keduanya ketika menambahkan fitur di sekitar Foo. Dalam proyek yang lebih besar ini bahkan lebih penting karena jarak antara folder teknis dapat menjadi besar dan menjadi buang-buang waktu saat berkembang.