DDD - Domain Driven Design, quale ordine di sviluppo deve essere applicato?

4

1 - Progetta le mie entità, cioè (in python):

class Account:
    def __init__(name, author):
        self.name = name
        self.email = email

2 - Progetta i miei repository: (come interfaccia)

class AccountRepository:
    def add(self, account):
        """ @type account Account """
        pass

    def find_by_name(self, name):
        pass

    def find_by_email(self, email):
        pass

    # remove, and others...

Ora, posso andare in due modi:

A: Progetta e implementa i miei servizi di dominio:

class SignUpService:
    def __init__(self, account_repository):
        """ @type account_repository AccountRepository """
        self._account_repository = account_repository

    def create_account(self, username, email):
        account = Account(username, email)
        self._account_repository.add(account)

    # other methods that uses the account_repository

B: Implementa le mie strategie di repository:

class MongodbAccountRepository(AccountRepository):
    def __init__(self, mongodb_database):
        self._mongodb_database = mongodb_database

    def add(self, account):
        account_data = account.__dict__
        self._mongodb_database.accounts.insert(account_data)

    # and the other methods

Qual è l'ordine corretto? e perché? 1, 2, A, B o 1, 2, B, A?

Grazie mille!

    
posta user3508219 07.04.2014 - 21:40
fonte

3 risposte

5

Innanzitutto vorrei iniziare con l'interfaccia utente, pensando alle attività / comandi che gli utenti devono eseguire e ai dati coinvolti in ogni attività / comando. Questo è noto come approccio UI basato sulle attività .

Queste attività formeranno un mapping 1-1 con i metodi forniti dai Servizi applicazioni (diversi da un servizio di dominio).

Quindi progetterei i miei aggregati sulla base di queste attività e amp; dati: una progettazione ottimale sarebbe per un'attività / transazione (chiamata al servizio dell'applicazione) che coinvolge un solo aggregato. Per me, questo è tutto ciò che riguarda la progettazione di aggregati basati sul comportamento.

Implemento solo servizi di dominio in cui una transazione deve cambiare stato su più di un aggregato. Questi Servizi di dominio escludono qualsiasi logica dal Servizio Applicazione (il cui compito è solo quello di orchestrare).

Lo storage sarebbe arrivato per ultimo: puoi implementare lo spazio di archiviazione solo quando sai esattamente cosa stai memorizzando?

Quindi il mio ordine completo è:

  1. UI

  2. Servizio applicazioni (io lo chiamo un servizio comandi)

  3. Dominio

  4. Aggregati

  5. Servizio dominio

  6. archiviazione

FYI Tendo a seguire i principi di CQRS , quindi l'interrogazione è anche un altro 'livello' che devo considerare, ma Ho appena dato l'ordine in termini di DDD e progettazione di aggregati.

Riguardo alla progettazione di aggregati, raccomando questi articoli di Vaughn Vernon

Ho anche scritto un blog riguardante la progettazione di aggregati basati sul comportamento.

    
risposta data 10.04.2014 - 12:40
fonte
2

A un livello hai risposto alla tua stessa domanda. Il tuo SignUpService utilizza un AccountRepository , quindi avrai bisogno di almeno qualche implementazione del repository solo per il test di base. A livello pratico, tuttavia, è probabile che vedrai più sfasamenti nei tuoi servizi man mano che ti avvicini al tuo dominio, quindi è probabile che dovrai impiegare più tempo.

Quindi, se stai cercando una regola empirica, direi innanzitutto di ottenere un'implementazione funzionante del repository. Non deve essere la tua versione di "produzione", ma dovrebbe essere in grado di guidare il sistema. Quindi assicurati che i tuoi servizi e il resto del dominio siano corretti. Il modello di dominio - non il livello di archiviazione - è da dove proviene il valore in DDD, quindi fallo bene e lascia che informi la scelta del back-end di archiviazione, non il contrario.

    
risposta data 24.04.2014 - 15:34
fonte
2

La mia opinione personale è che si dovrebbe iniziare dove si trova la logica aziendale e che è il dominio. Anche se dovessi implementare una sola user story al momento, dovresti iniziare dal dominio e dalle operazioni nel dominio. Si dovrebbe anche applicare la stessa lingua (il linguaggio ubiquo) nel dominio.

Dopo che è stato implementato e testato, il riposo arriva naturalmente. Implementa problemi di infrastruttura, servizi applicativi, interfaccia utente.

    
risposta data 05.12.2017 - 09:37
fonte

Leggi altre domande sui tag