Il ben noto ID aziendale di un'entità deve essere rappresentato con un tipo dedicato in DDD / OOP?

Se puoi fornire alla classe funzionalità utili sufficienti a giustificare la complessità aggiuntiva di non essere una stringa, fallo. Per identificatori come ISBN e ISIN, sospetto che non sia così.

Affinché una classe identificatore sia utile, mi aspetto che assomigli a qualcosa del tipo:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

Se invece è più simile a questo:

class ISIN {
    getString()
    setString()
}

Quindi eliminerei completamente la classe, userei stringhe regolari ovunque e assicurarmi di usare costantemente "isin" in tutti i nomi delle variabili rilevanti.

Si noti che in alcune lingue, l'aggiunta di un nuovo tipo non ha quasi nessuna "complessità aggiunta" nei programmi tipici, nel qual caso si sarebbe incoraggiati a creare il nuovo tipo anche se non aveva alcuna funzionalità. Ma questo non è il caso della maggior parte dei linguaggi OOP tradizionali come il C ++.

Direi di provarci. Direi che i vantaggi superano gli svantaggi in questo caso. È probabile che il codice aggiuntivo sia piuttosto minimale e il problema della persistenza possa essere risolto abbastanza facilmente fornendo una sorta di convertitore tra la nuova classe e il tipo che il database si aspetta (non ho mai usato Entity Framework ma so che questo è relativamente indolore Hibernate).

Uno dei vantaggi che puoi ottenere definendo la tua classe è che il compilatore può garantire che tutti i metodi che vogliono un codice ISBN o ISIN possano sapere in tempo di compilazione se provi a passare valore sbagliato. Sarà anche molto più difficile sovrascrivere accidentalmente quel campo nella tua entità. Possiamo evitare errori comuni come questo:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

Se il codice ISBN è una classe piuttosto che un tipo primitivo, il codice precedente non verrà nemmeno compilato, risparmiando un sacco di tempo di debug in seguito.