Modellazione del dominio di gestione dei contenuti

Quindi le domain-driven-design

No domain expert will say "We create a published article from this article"

È vero, ma potresti sentirli dire che abbiamo pubblicato questa bozza ; o abbiamo pubblicato questa submission (non la stessa cosa). O che è stata pubblicata una revisione (anche non la stessa cosa).

Article as an aggregate through which the current version and the published version can be accessed. But it seems weird as it basically references it's own versions

Non proprio strano, pensate al controllo del codice sorgente; abbiamo una cronologia di documenti e tag che ci dicono quale elemento in quella cronologia è l'istantanea di sviluppo corrente e che è stata utilizzata per la compilazione notturna e che è stata utilizzata per l'ultima versione ....

Split the problem into two context (editing and publishing)

Forse - due contesti (nel senso di contesti delimitati dal libro blu) di solito significa pubblici diversi che usano lo stesso linguaggio con semantica diversa. Se "editori" significano una cosa quando dicono "articolo", e gli editori significano una cosa diversa, allora due contesti diversi possono aiutare con quello.

Ma se gli editori e gli editori condividono lo stesso vocabolario, allora potresti cercare due diversi aggregati.

I looked into state pattern but got lost trying to understand how to actually use it in my concrete example.

Lo schema di stato funziona molto bene per i processi; il trucco è che l'istanza del processo e il documento che sta attraversando il processo sono cose diverse. Si tiene traccia del lavoro svolto (macchina a stati) e uno è il lavoro (documento).

Still curious about the state pattern. Can you elaborate on how it can possibly look in my scenario, please?

I processi tendono ad andare bene con "event sourcing" - lo stato attuale di un processo è solo una piega degli eventi che sono accaduti finora.

DraftCreated
DraftModified
DraftSubmitted
SubmissionRejected
DraftModified
DraftSubmitted
SubmissionApproved
ArticlePublished
ArticleRetracted
...

Quindi immagina una macchina di stato ; si inizia in uno stato Begin e ogni volta che si vede che qualcosa è successo, si notifica l'istanza della macchina dell'evento e it calcola lo stato successivo .

Metaforicamente, abbiamo un pezzo di carta (l'articolo) all'interno di una busta (il processo). Ogni volta che qualcuno fa qualcosa al documento, scrive quello che ha fatto sulla busta. Potresti immaginare questa busta che passa da una casella di posta in entrata alla successiva.

Lo stato attuale è fondamentalmente il bit che risponde alle domande; dato cosa è successo finora, che cosa può succedere dopo? chi stiamo aspettando? quanto ci è voluto? quanto dovrebbe essere pagato l'autore? e così via

Una serie di domande molto diversa da quelle che chiederesti al documento: qual è il tuo titolo? quanto tempo sei? che livello di lettura sei? e così via.

L'ho fatto in questo modo:

• Article.Save: crea un nuovo articolo con un nuovo numero di versione e contenuto specificato

• Pubblicazione?. Pubblicazione (articolo) - aggiunge / aggiorna un oggetto PublishedArticleVersionNumber con il numero di versione specificato

• Article.Load (versionId) - Restituisce la versione selezionata / ultima dell'articolo per la modifica.

È estremamente flessibile, perché non si elimina mai un articolo e si separa la pubblicazione dalla creazione e dalla modifica.

Tuttavia, mangia molto spazio sul disco a meno che non si faccia qualcosa di intelligente nell'archiviazione di tutte quelle revisioni. Puoi salvare delta, usare Event Sourcing o semplicemente eliminare vecchie versioni. Opzione più semplice, acquista dischi rigidi più grandi

Per aggiungere altre buone risposte qui e per essere un po 'più meta, dovremmo (essere in grado di) fare i nostri progetti di dominio direttamente in termini di dominio a cui il cliente è abituato, e senza alcun riferimento a schemi di implementazione come lo stato modello.

Lo schema di stato può effettivamente essere applicato durante la codifica, ma è prematuro considerare a questo punto.

Il design di un dominio deve catturare le entità e le loro relazioni, che saranno guidate da ciò di cui gli utenti hanno bisogno per parlare e da realizzare nel tempo.

In DDD una delle prime cose che vuoi fare è stabilire un vocabolario comune tra gli utenti all'interno del dominio. Questo vocabolario comune è integrato nelle entità e nelle relazioni. Alla fine, il vocabolario viene incorporato in funzionalità e comportamenti, tramite codice. Quando arriviamo al codice, si applicano modelli comportamentali del software (ad esempio pattern di stato).

Mi piace @ VoiceOfUnreason che prende in giro le bozze di pubblicazione e la pubblicazione oltre l'articolo a termine sovraccarico.

Potrei pensare che potresti anche preoccuparti di avere un'identità dell'articolo stabile o di avere relazioni esplicite tra le bozze, in modo tale che una serie di bozze possa supportare la modifica del titolo oltre ad altri contenuti. Qualcosa da chiedere ai tuoi esperti di dominio.