Come iniziare a utilizzare DDD nella progettazione di un'applicazione "libreria"

Hai considerato il libro "Implementing Domain Driven Design" di "Vaugh Vernon"? Fornisce una visione dei concetti alla base del DDD da un punto di vista dell'implementazione con un sacco di esempi reali davvero buoni.

Riguardo alle tue domande esplicite:

L'architettura pulita, come affermato da Maciej Chałapuk, è ortogonale a DDD. È un concetto solido e solido per strutturare il sistema e dare spazio a concetti di modellazione di dominio come DDD.

Non penserei troppo alla struttura esplicita di questo contesto limitato. Prova a scrivere un test di accettazione molto ampio di un caso di uso di base contro il limite del sistema esterno. Cerca di implementarlo con il minor numero possibile di interlocutori mantenendo una ragionevole separazione tra i componenti creati. Scrivi Test unitari se applicabile.

Preferisco questo approccio esterno ("Un software orientato agli oggetti in crescita, guidato da test" è un buon riferimento qui), poiché guida un modello di dominio meno placcato in oro e più adatto ai casi d'uso reali.

I am not able to find any value object till now or I am not able to recognize / find it?

Gli oggetti valore potrebbero essere difficili da trovare in alcuni domini, anche se nel tuo caso probabilmente rendere ISBN un oggetto valore poiché ha una struttura definita in modo formale e vi è una logica aziendale connessa con esso. A volte è una decisione di progettazione se rappresentare qualcosa come un oggetto di valore o un'entità o solo un campo di un'entità.

I have followed Clean Architecture for some time and helped to build a toy project before. What is the difference between this and DDD?

Queste sono due cose completamente diverse.

1. Clean Architecture è un Pattern architettonico che definisce la struttura di un intero programma.
2. DDD è un metodo per modellare Logica di dominio e separarlo dal resto del programma.

Sono ortogonali tra loro (entrambi possono essere applicati nello stesso programma).

Am I on the right track?

Sì, sei sulla strada giusta con la modellazione. La migliore fonte di conoscenza su DDD è il libro di Eric Evans (autore del metodo).

Assicurati che i metodi delle entità e degli oggetti valore contengano solo la logica del dominio (cambiamenti di stato e vincoli). Tutto il codice specifico della piattaforma dovrebbe essere altrove (presentazione, persistenza, registrazione, threading, ecc.). Le entità dovrebbero avere metodi di dominio che prendono il nome dalle operazioni aziendali. Questi metodi dovrebbero essere chiamati dai servizi (solo una chiamata / entità / operazione nella maggior parte dei casi).

SearchBook (Takes a title and gives the result back)

Sei sicuro di aver bisogno di un servizio per questo? Sembra che questa sia una responsabilità di un repository, a cui è stata data una Specifica , contenente il titolo del libro.

BorrowService (Checks if a book can be borrowed)

Sei sicuro che questa non è solo la proprietà inStock di un oggetto Book? Oppure, se si dispone di alcuni calcoli di quantità, dovrebbe esserci un oggetto, responsabile di ciò.

Member service (Enroll/Unroll members in a library)

Che cosa farà questo servizio? Creare / eliminare utenti è responsabilità di un repository.

Book (ISBN number as a UID)

Non sono sicuro che questa sia una buona scelta di chiave primaria. Un libro può avere due ISBN o anche di più. Non sono sicuro che riuscirai a trovare una buona chiave naturale per i libri.

User (Email as UID, it can be author or reader)

Quindi, l'utente non sarà in grado di collegare l'e-mail secondaria al suo account, giusto? Inoltre, se scegli l'e-mail come chiave primaria, il collegamento con l'utente in altre tabelle aumenterà la crescita degli indici. Ancora una volta, non sono sicuro di poter trovare qui una chiave naturale adatta.

I am not able to find any value object till now or I am not able to recognize / find it? I haven't find any so far also ;)