Devo organizzare le mie cartelle per dominio aziendale o dominio tecnico?

Ad esempio, se sto usando un'architettura simile a MVC, quale struttura di cartelle dovrei usare:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

O:

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

Ho deliberatamente lasciato fuori le estensioni dei file per mantenere questa domanda indipendente dal linguaggio.

Personalmente, preferirei separare per dominio aziendale (sensazione viscerale), ma vedo che la maggior parte / molti framework separati dal dominio tecnico. Perché dovrei scegliere l'uno rispetto all'altro?

Penso che questo dipenda da un progetto specifico.

Ad esempio, se i diversi domini aziendali sono totalmente indipendenti l'uno dall'altro, allora organizzerei per dominio aziendale.

Ma se esiste un codice condiviso tra i domini aziendali, o meglio, i domini aziendali sono varianti diverse della stessa base di codice, allora sembra più logico organizzare per dominio tecnico. E se usi qualsiasi tipo di linguaggio orientato agli oggetti, puoi probabilmente sottoclassare i tuoi controller, modelli, ecc. Generici nei tuoi file aziendali specifici per renderli più sottili.

Esiste anche una via di mezzo (dorata) tra i due: rimuovere il codice condiviso nel proprio dominio e usarlo in altri domini. Questo ti dà il tuo layout basato sul sentimento, ma consente il codice condiviso tra domini aziendali.

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. Penso che la maggior parte dei framework si organizzi per dominio tecnico solo perché tendono ad aspettarsi di mescolare domini aziendali diversi in un singolo progetto solo se si dispone di codice condiviso e altrimenti si creerebbero progetti separati.

MODIFICARE:

Ad esempio, supponiamo che esista un'app Web che gestisce il magazzino di un'azienda. In forma generica questo potrebbe applicarsi a molte aziende, ma ognuna di esse potrebbe avere alcuni dettagli che non sono stati rispettati e proibisce loro di acquistarli. Ad esempio, uno di essi ha distribuito tablet sui carrelli elevatori e ha bisogno di una visualizzazione speciale per loro, mentre un altro vuole per organizzare gli elementi in tre livelli anziché il valore predefinito di due.

Ovviamente potresti sborsare il progetto per ognuna di queste aziende. Ma se il framework / linguaggio lo consente, è possibile utilizzare la sottoclasse o i plug-in ecc. Per personalizzare parti del progetto generico in base alle esigenze di ogni cliente e organizzarle nei layout del dominio aziendale.

Ad esempio, se un progetto generico esporta in JSON solo l'elemento stesso, Domain1 può sottoclassare il controller e far esportare anche i recenti problemi di consegna.

E se successivamente scopri che Domain1 ha un componente valido anche per Domain2, puoi estrarne una versione generica su Shared.

Come hai detto, molti framework si organizzano in base al dominio tecnico ed è quello che ho usato per ora, solo perché il mio FW di scelta lo rende più facile. Ma con un po '(o molto) di grasso per gomiti, penso di poter riscrivere i percorsi di inclusione per supportare anche il layout del dominio aziendale.

Penso che sia illuminante chiedere: "cosa ho maggiori probabilità di aggiungere su base regolare, più domini o più divisioni tecniche?" Quindi, qualunque sia la risposta, mettila al livello più alto.

Nella maggior parte dei casi la tua architettura tecnica si solidificherà più velocemente del tuo dominio. Ciò significa che è necessario organizzarsi prima per dominio, quindi per componente architettonico. Il motivo è che quando qualcosa cambia in un dominio, potresti dover aggiungere o modificare più componenti tecnici in quel dominio, ma si spera che sia localizzato e non si riversi molto in altri domini.

Se hai cambiato il tuo framework GUI, ciò significa che le tue modifiche si estenderanno all'intera applicazione, ma poi di nuovo, raramente cambi il tuo framework GUI, ma cambi sempre la logica del tuo dominio.

Tieni le cose insieme se è probabile che cambino allo stesso tempo.

C'è un'altra alternativa e che sta spostando le parti separate nei plugin. CakePHP lo fa per esempio. Ti consentirà di generare parti MVC complete che sono riutilizzabili e che puoi ordinare in base a qualsiasi logica desideri.

L'applicazione principale li utilizzerà e li collegherà.

Fondamentalmente la tua domanda riguarda anche la coesione e l'accoppiamento. Volete che le parti separate funzionino nel modo più indipendente possibile. In questo modo ottieni codice testabile e riutilizzabile.

Tenendo conto di ciò: se si dividesse per dominio come riutilizzeresti parti della tua applicazione? Ad esempio, prendi un negozio online: arriva una richiesta per / ordini / vista / 1, quindi devi mostrare l'ordine n. 1. Vai a / ordini / controller / order_controller Se hai separato il dominio dai prodotti e dagli ordini avresti già bisogno di parti dell'altro "dominio".

Lì puoi iniziare a interfacciare le cose, ma probabilmente le cose sono nella maggior parte degli affari troppo coese. Se prendi l'approccio tecnico. Ad esempio, potresti avere un plug-in per la gestione degli ordini. Gli oggetti Prodotto vengono inseriti dall'applicazione centrale. In questo modo puoi testare facilmente il plugin, basta creare un oggetto Prodotto con un nome e un prezzo e inviarlo.

Il plugin farà esattamente ciò che deve fare. Dipenderà dal suo input e non da altre "parti / domini / aree".

Microsoft ASP.Net MVC 3 ha il concetto di "Aree". Quando introduci "Aree" nel tuo progetto MVC, lo suddividono come:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Ho trovato questo abbastanza naturale. Un'area è un "grosso pezzo" di un progetto e lavorare in un'unità autonoma ha molto senso.

Abbiamo usato gli spazi dei nomi per abbinare, FWIW.

Dalla mia esperienza personale con un negozio online composto da 300000 righe di codice, andrei sempre per l'organizzazione per dominio aziendale. In questo modo, non solo è possibile ottenere una rapida panoramica di tutte le classi rilevanti quando si lavora su un'area funzionale, in Java è anche possibile utilizzare la visibilità del pacchetto.

Alcuni dettagli per coloro che sono interessati: Quando il progetto è stato avviato 5 anni fa, gli sviluppatori hanno creato la seguente struttura di pacchetti:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Ogni funzione del negozio come carrello della spesa, ricerca di prodotti, ecc. Consiste in diverse azioni, ognuna con la propria classe di forma (struttura obbligatoria del framework MVC). Ciò che abbiamo finito sono oltre 200 classi nel pacchetto di azioni, ognuna completamente separata dalla loro classe di modulo associata. Quel che è peggio è che le azioni non implementano troppa logica, ma chiamano servizi specifici per funzione che risiedono in un altro pacchetto.

Ho suggerito e convinto il team che dovremmo passare all'organizzazione dei pacchetti per dominio aziendale. Il ragionamento è semplice: se vuoi davvero vedere un elenco di tutte le azioni, puoi semplicemente aprire la visualizzazione della gerarchia dei tipi di qualsiasi IDE decente. Tuttavia, ciò che l'IDE non può fare è inferire il dominio aziendale a cui appartiene una classe. Inoltre, questo approccio consente di rendere pubbliche solo le classi necessarie per diverse funzionalità, mantenendo il resto sulla visibilità del pacchetto.

Concordo sul fatto che molti framework si separano per dominio tecnico e quindi spesso inizio in questo modo quando utilizzo un nuovo framework. Tuttavia, mi accetto costantemente all'utilizzo del dominio aziendale come livello primario dell'organizzazione delle cartelle.

Personalmente, penso che sia molto più facile tenere il mio Foo Controller e il Foo Repository o qualsiasi cosa insieme piuttosto che andare avanti e indietro tra la cartella del Controller e la cartella del Repository come spesso ho bisogno di lavorare su entrambi quando si aggiungono funzionalità a Foo. Nei progetti più grandi questo è ancora più importante in quanto la distanza tra le cartelle tecniche può essere grande e diventare una notevole perdita di tempo durante lo sviluppo.