Approccio basato sul Domain Driven Design per il gioco

Non userei DDD per questo. Il punto di DDD è organizzare il codice in parti discrete e non riutilizzabili per garantire affidabilità e prevedibilità.

Affinché il tuo gioco possa essere modificato e aggiunte nuove funzionalità, riuscire a riutilizzare le entità sarebbe di grande aiuto. L'aggiunta di nuove funzionalità è più importante per un gioco che garantire l'assoluta affidabilità.

In DDD, spesso sviluppi volutamente un modello di dominio anemico; un modello di dominio anemico sarebbe disastroso per il tempo di sviluppo della maggior parte dei giochi.

In breve, un gioco sarebbe l'ultimo posto in cui vorrei usare DDD.

Tuttavia, ciò non significa che non puoi prendere alcuni dei principi di DDD e sfruttarli, non è tutto o niente.

Ad esempio, il processo di registrazione sarebbe un candidato per essere un dominio completamente diverso rispetto al gioco stesso.

Il modo migliore per impedire che i comportamenti interferiscano l'uno con l'altro è ridurre l'accoppiamento e utilizzare le interfacce quando possibile; questo può essere fatto in più modi rispetto al solo DDD.

Dopo aver lavorato così duramente al progetto. Non pensare completamente al DDD.

Ma il DDD adattato funziona molto bene.

In primo luogo, se ci pensiamo attentamente, prendiamo solo alcune parti dal DDD. Limitando un dominio. Questo rende ogni dominio una singola responsabilità.

Penso che DDD sia un modo di pensare per progettare domini e stati.

Ecco alcuni esempi di domini:

• Player
• gioco
• Bandiera

Quindi separiamo il contesto limitato.

• FlagCapture BC potrebbe avere

  • PlayerFlagCapture
  • FlagCapture

• Vita BC

  • PlayerLife

• HealthPoint BC

  • PlayerHealthPoint

Ora adattato CQRS, applichiamo l'evento ad ogni modifica e ritagliamo la parte di comando.

Perché la ragione per avere eventi in CQRS è di tracciare ogni singola modifica dei domini. E la ragione per avere un comando in CQRS riguarda la comunicazione tra i microservizi.

Quindi aggiungiamo le logiche cross-aggregate avendo EventHandlers.

E non rendere la tua architettura densa. Non ho un adattatore per comunicare tra BC. Solo interfaccia se necessario.

Inoltre, Nessuna infrastruttura, Nessun repository, Nessun servizio, Nessun livello applicazione e nessun ID effettivo all'interno di un dominio perché tutto il dominio sarà incorporato in un singolo GameObject / GameEntity che avrà ID condiviso.

In questo modo otteniamo molti benefici dal DDD & adattato CQRS.

• Riproduci tutto il gameplay.
• Sincronizza stato quando un nuovo dispositivo si unisce tra di loro.
• Altissima modularità.

Verrò aggiornato più tardi dopo aver completato il mio progetto.

UPDATE:

Attualmente sto lavorando su un'architettura ECS invece di accedervi prima su DDD.

ECS ha disaccoppiato quasi tutto e puoi consentire a chiunque lavori in team su qualsiasi sistema indipendentemente.

Come diceva la risposta, Game would be the last place to use DDD , DDD è migliore su più distribuzioni su micro-servizi, senza interazione troppo frequente tra domini.