Devo organizzare le mie cartelle in base al dominio aziendale o tecnico?

Penso che ciò dipenda da un progetto specifico.

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

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

C'è anche una (a metà) golden tra le due - elimina il codice condiviso nel proprio dominio e lo usa in altri domini. Questo ti dà il tuo layout intuitivo, ma consente il codice condiviso tra i 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 organizzi per dominio tecnico solo perché tendono ad aspettarsi di mescolare diversi domini aziendali in un singolo progetto solo se hai codice condiviso e altrimenti creerai progetti separati.

Modifica

Ad esempio, supponiamo che esista un'app Web che gestisce il magazzino di un'azienda. In forma generica ciò potrebbe applicarsi a molte aziende, ma ognuna di esse potrebbe avere alcune specifiche che non sono soddisfatte e proibisce loro di acquistare. Ad esempio, una di queste ha distribuito tablet ai carrelli elevatori e ha bisogno di una Vista speciale per loro mentre un altro vuole ancora. per organizzare gli elementi in tre livelli invece del valore predefinito di due.

Ovviamente potresti forgiare il progetto per ciascuna di queste società. Tuttavia, se il framework / linguaggio consente, è possibile utilizzare la sottoclasse oi plugin ecc. Per personalizzare i bit e le parti del progetto generico in base alle esigenze di ogni cliente e organizzarli nei layout di Dominio aziendale.

E.g se il progetto generico esporta in JSON solo l'elemento stesso, Domain1 può creare sottoclasse del controller e fargli esportare anche problemi di consegna recenti.

E se successivamente scopri che Dominio1 ha un componente valido anche per Dominio2, puoi estrapolarne la versione generica su Condiviso.

Come hai detto, molti framework si organizzano per 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 gomito, penso che potrei riscrivere i percorsi di inclusione per supportare anche il layout di Business Domain.

C'è un'altra alternativa e questo è lo spostamento delle 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 alla logica che desideri.

La tua applicazione principale li userà e ti collegherà a loro.

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

Prendendo in considerazione questo: se ti dividi per dominio come utilizzeresti di nuovo parti della tua applicazione? Ad esempio, prendi un negozio online: arriva una richiesta per / orders / view / 1 quindi devi mostrare l'ordine nr. 1. Passa a / orders / controller / order_controller Se hai un dominio separato per prodotti e ordini, avresti già bisogno di parti dell'altro "dominio".

Qui puoi iniziare ad interfacciare le cose ma probabilmente le cose sono nella maggior parte degli affari solo troppo coese. Se segui l'approccio tecnico. Ad esempio potresti avere un plugin per gestire gli ordini. Gli oggetti del prodotto vengono inseriti dall'applicazione centrale. In questo modo puoi testare facilmente il plugin, basta creare un oggetto Product 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 presenti "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 abbinarli, FWIW.

Dalla mia esperienza personale con un negozio web composto da 300 000 righe di codice, vorrei sempre organizzarmi per dominio aziendale. In questo modo, non solo puoi ottenere una rapida panoramica di tutte le classi rilevanti quando lavori su un'area funzionale, in Java puoi anche 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 del pacchetto:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Ogni funzione del negozio come carrello della spesa, ricerca del prodotto, ecc. consiste in diverse azioni, ognuna con una propria classe di moduli (struttura dettata dal framework MVC). Quello che abbiamo finito sono oltre 200 classi nel pacchetto azione, ognuna completamente separata dalla classe della classe associata. Quel che è peggio è che le azioni non implementano troppa logica, ma chiamano servizi specifici della 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 vista sulla gerarchia dei tipi di qualsiasi IDE decente. Tuttavia, ciò che l'IDE non può fare è dedurre il dominio aziendale a cui appartiene una classe. Inoltre, questo approccio ti consente di rendere pubbliche solo quelle classi che sono necessarie per diverse funzionalità, mantenendo il resto sulla visibilità del pacchetto.

Sono d'accordo sul fatto che molti framework sono separati dal dominio tecnico e quindi spesso inizio in questo modo quando utilizzo un nuovo framework. Tuttavia, mi impegno sistematicamente a utilizzare il dominio aziendale come livello principale dell'organizzazione di cartelle.

Personalmente, penso che sia molto più facile mantenere il mio Foo Controller e Foo Repository o qualsiasi altra cosa insieme che andare avanti e indietro tra la cartella del Controller e la cartella del Repository come spesso devo lavorare su entrambi quando aggiungo 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.