Arsitektur (struktur) berorientasi pada struktur proyek berorientasi fitur


14

Proyek ini, saya telah terlibat, memiliki struktur file / folder proyek yang berorientasi arsitektur:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

Ini jelas dari sudut pandang arsitektur sistem (telah diusulkan oleh tim pengembangan).

Ini adalah struktur berorientasi fitur yang telah diusulkan oleh tim desainer:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

Varian ini lebih dekat dengan desainer dan jelas menggambarkan fitur yang harus diimplementasikan.

Tim kami telah memulai perang suci: apa pendekatan terbaik. Bisakah seseorang membantu kami dan menjelaskan kontra dan pro dari yang pertama dan kedua. Mungkin ada yang ketiga yang lebih bermanfaat dan bermanfaat bagi kita berdua.

Terima kasih.


Saya tidak mengerti struktur mana pun - apa perbedaan antara Acara dan Permintaan (dan karenanya Penangan Acara dan Penangan Permintaan)?
Peter Boughton

1
Pertanyaan yang sangat jelas - dan netral juga!
Michael K

1
Dari perspektif skalabilitas, pendekatan kedua harus cukup mudah untuk skala secara horizontal.
CodeART

Jawaban:


11

Saya akan memilih yang kedua. Dalam struktur pertama, penangan event untuk FeatureAsepenuhnya tidak terkait dengan penangan event untuk FeatureB. Tampaknya pengembang akan mengerjakan satu fitur pada satu waktu, dan jika Anda mengerjakan FeatureXpermintaan, jauh lebih mungkin bahwa Anda perlu mengubah FeatureXpenangan permintaan daripada, katakanlah, FeatureZpermintaan.

Ngomong-ngomong, saya suka bagaimana Anda mengajukan pertanyaan ini dari sudut pandang netral.


1
+1 dengan satu peringatan: untuk proyek-proyek kecil, yang kedua akan menghasilkan struktur file yang lebih besar daripada ada file untuk dimasukkan. Saya akan menggunakan yang pertama untuk itu.
Michael K

@Michael saya setuju, tetapi dalam hal ini adalah proyek besar.
Zzz

1
+1: Dan jika Anda harus berkomunikasi dengan pengguna / klien, maka terminologinya bisa sangat konsisten.
Steven Evers

4

Saya selalu lebih nyaman dengan pendekatan kedua, tetapi saya selalu memiliki "fitur" yang disebut umum atau umum untuk kelas yang benar-benar digunakan bersama / basis.

Pendekatan dua membuat hal-hal yang terpisah benar-benar terpisah, tetapi tanpa daerah "umum" itu kadang-kadang memisahkan hal-hal menjadi daerah yang mereka tidak cocok.


+1 untuk umum dan umum (setiap proyek memiliki utilitas umum, alat ...)
Zzz

3

Mengapa fitur-penemu peduli dengan detail implementasi? Jika itu adalah pemisahan antara sisi argumen, maka saya pikir jawabannya jelas. Orang yang menciptakan ide / fitur tidak menentukan struktur file yang dibutuhkan oleh pelaksana.

Ini adalah masalah yang sangat penting ketika implementasi fitur mencakup beberapa dll, exes, database, atau perangkat lunak lainnya.


1
Saya memikirkan hal itu, tetapi, semua hal lain dianggap sama, pendekatan kedua memiliki beberapa keuntungan filosofis yang jelas untuk semua aplikasi yang paling sepele. Paling tidak, itu saran yang bagus.
Robert Harvey

@Robert Harvey: Jika Anda berbicara tentang organisasi idealogis proyek, maka saya perlu memikirkan jawaban baru. Namun, sepertinya mereka berbicara tentang file yang berisi kode ...
John Fisher

Kuncinya adalah pemisahan fitur menjadi ember yang berbeda. Untuk semua aplikasi kecuali yang terkecil, Anda akan memerlukan semacam organisasi seperti ini, apakah Anda merujuk pada struktur folder, struktur kelas atau konvensi namespace.
Robert Harvey

1
@Robert Harvey: Bagaimana dengan masalah pembangunan dan penyebaran? Bagaimana dengan hal-hal sederhana seperti hanya bisa menggunakan IDE untuk menulis dan men-debug kode? Beberapa hal ini harus memiliki dampak kuat pada struktur folder.
John Fisher

1

Harus setuju dengan pendekatan kedua, mengingat dua opsi. Yang pertama hanya terlihat seperti gumpalan amorf. Setidaknya yang kedua memiliki beberapa bentuk.

Itu benar-benar tergantung pada seberapa besar proyek itu. Jika "fitur" besar, masing-masing membutuhkan ember yang berbeda.


1

Saya tidak mengerti terminologi yang Anda gunakan, tetapi akan mencoba menjawabnya, karena kedua struktur tampaknya merupakan pendekatan yang salah.

Kecuali jika Anda hanya memiliki sedikit fitur, Anda perlu mengelompokkannya ke dalam kategori - dan itu tampaknya tidak dipenuhi dalam kedua desain (kecuali jika itu yang dimaksudkan oleh Node1, tetapi "semua X proyek" menyarankan jika tidak, dan membuat saya bertanya-tanya apakah itu WTF - apakah ada Node2?)

Saya mungkin mempertimbangkan sesuatu seperti ini:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Atau ini:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


Tapi mereka berdua membuat asumsi yang mungkin benar-benar tidak aktif - jika Anda dapat memperbarui pertanyaan Anda dengan lebih detail, saya mungkin berubah pikiran. :)

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.