Implementazione di DDD: utenti e autorizzazioni

Sto lavorando a una piccola applicazione cercando di comprendere i principi della progettazione guidata dal dominio. In caso di successo, questo potrebbe essere un pilota per un progetto più ampio. Sto cercando di seguire il libro "Implementing Domain-Driven Design" (di Vaughn Vernon) e sto cercando di implementare un forum di discussione simile e semplice. Ho anche controllato i campioni IDDD su github. Ho delle difficoltà ad adottare l'identità e l'accesso al mio caso. Vorrei fornire alcune informazioni di base:

• Comprendo (si spera) il ragionamento alla base della separazione degli utenti e della logica dei permessi: è un dominio di supporto ed è un contesto limitato diverso.
• Nel dominio principale, non ci sono utenti, solo autori, moderatori, ecc. Questi vengono creati raggiungendo il contesto di identità e accesso utilizzando un servizio e quindi traducendo gli oggetti utente ricevuti in e moderatore.

• Le operazioni di dominio vengono chiamate con un ruolo correlato come parametro: ad es .:

  ModeratePost( ..., moderator);

• Il metodo dell'oggetto dominio controlla se l'istanza del moderatore fornita non è nulla (l'istanza del moderatore sarà nulla se l'utente richiesto dal contesto Identità e accesso non ha il ruolo di moderatore).

• In un caso, effettua un controllo aggiuntivo prima di modificare un Post:

  if (forum.IsModeratedby(moderator))

Le mie domande sono:

• In quest'ultimo caso, i problemi di sicurezza non vengono nuovamente integrati nel dominio principale? In precedenza il libro indica "con chi può pubblicare un argomento o a quali condizioni è consentito. Un forum deve solo sapere che un autore lo sta facendo proprio ora".

• L'implementazione basata sul ruolo nel libro è abbastanza semplice: quando un Moderatore è il dominio principale cerca di convertire l'ID utente corrente in un'istanza del Moderatore o in un Autore quando ne ha bisogno. Il servizio risponderà con l'istanza appropriata o null se l'utente non ha il ruolo richiesto. Tuttavia, non riesco a vedere come potrei adattarlo a un modello di sicurezza più complesso; il nostro attuale progetto per cui sto pilotando ha un modello piuttosto complesso con gruppi, ACL, ecc.

Anche con regole non molto complesse, come ad esempio: "Un post dovrebbe essere modificato solo dal suo proprietario o da un editore", questo approccio sembra fallire, o almeno non vedo il modo corretto di implementarlo.

Chiedere al contesto Identity and Access un'istanza di OwnerOrEditor non sembra corretto e finirei con un numero sempre maggiore di classi relative alla sicurezza nel dominio principale. Inoltre, dovrei passare non solo l'ID utente, ma l'identificatore della risorsa protetta (l'id del post, il forum, ecc.) Al contesto di sicurezza, che probabilmente non dovrebbe interessare a queste cose (è corretto? )

Estraendo i permessi dal dominio principale e controllandoli nei metodi degli oggetti del dominio o nei servizi, finirò al punto di partenza: mescolare i problemi di sicurezza con il dominio.

Ho letto da qualche parte (e tendo a concordare con esso) che queste cose relative alle autorizzazioni non dovrebbero far parte del dominio principale, a meno che la sicurezza e le autorizzazioni non siano il dominio stesso stesso. Una semplice regola come quella sopra giustificata rende la sicurezza parte del dominio principale?

A volte è difficile distinguere tra regole di controllo reale degli accessi e invarianti di domini che rasentano il controllo degli accessi.

In particolare, le regole che dipendono dai dati disponibili solo nel corso di una particolare logica del dominio potrebbero non essere facilmente estraibili dal dominio. Di solito, il controllo di accesso viene chiamato prima o dopo l'esecuzione di un'operazione di dominio ma non durante.

L' assert (forum.IsModeratedBy(moderator))esempio di Vaughn Vernon probabilmente avrebbe dovuto essere al di fuori del Dominio, ma non è sempre fattibile.

Avrei bisogno di passare non solo l'ID utente, ma l'identificatore della risorsa protetta (l'id del post, forum, ecc.) Al contesto di sicurezza, che probabilmente non dovrebbe interessare a queste cose (è corretto?)

Se c'è un Security BC e vuoi che gestisca quella logica, non deve sapere che cos'è un forum in dettaglio ma:

• Potrebbe semplicemente conoscere concetti come "moderato da" e concedere o negare i diritti di accesso di conseguenza.
• È possibile disporre di una logica dell'adattatore che si iscrive agli eventi del dominio principale e li traduca in coppie di valori-chiave semplici (risorsa, utente autorizzato) che il BC BC di sicurezza può archiviare e utilizzare.

Autenticazione e autorizzazione è un cattivo esempio per DDD.

Nessuna di queste cose fa parte di un dominio a meno che la tua azienda non crei prodotti di sicurezza.

Il requisito aziendale o di dominio è o dovrebbe essere "Richiedo l'autenticazione basata sul ruolo"

Quindi si controlla il ruolo prima di chiamare una funzione di dominio.

Laddove hai requisiti complessi come "Posso modificare i miei post ma non altri", assicurati che il tuo dominio separi la funzione di modifica EditOwnPost()e EditOthersPost()che tu abbia una semplice funzione per la mappatura dei ruoli

È anche possibile separare la funzionalità in oggetti di dominio, come ad esempio Poster.EditPost()e Moderator.EditPost()questo è un approccio più OOP, anche se la scelta può dipendere dal fatto vostro metodo è in un dominio del servizio o di un oggetto di dominio.

Tuttavia, si sceglie di separare il codice che verrà eseguito il mapping dei ruoli al di fuori del dominio. quindi ad esempio se hai un controller webapi:

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

Come si può vedere, anche se la mappatura ruolo viene eseguita sullo strato di hosting, il complesso logica di ciò che costituisce modificare il proprio o un altro post fa parte del dominio.

Il dominio riconosce la differenza delle azioni, ma il requisito di sicurezza è semplicemente che "la funzionalità può essere limitata dai ruoli" .

Questo è forse più chiaro con la separazione degli oggetti di dominio, ma essenzialmente si sta verificando il metodo che costruisce l'oggetto invece del metodo che chiama il metodo di servizio. Il tuo requisito, se vuoi ancora esprimerlo come parte del dominio diventerebbe "solo i moderatori possono costruire l'oggetto moderatore"