DDD non specifica in realtà come scrivi metodi o classi, quindi non vedo l'ereditarietà come in conflitto con DDD, anche con i Root aggregati.
I root aggregati hanno identità che sono usate per riferirsi ad essi dall'esterno del contesto limitato. Supponendo che l'oggetto dei sottotipi condivida tutti lo stesso spazio di identità (ad esempio, le loro identità sono uniche all'interno, cioè non si sovrappongono). Questo è tutto ciò che è necessario.
A Property is created with only it's main 8 attributes. After that the other aspects like addition of Attributes or choice of PropertyType are added to the Property. Does this mean 3 separate aggregate roots?
Puoi determinare se hai bisogno di più AR se hai concetti separati a cui fare riferimento indipendentemente dal contesto. In questo caso, la domanda a cui devi rispondere è se un Attribute viene aggiunto al sistema e ha un'identità stabile che può essere utilizzata al di fuori del contesto limitato. Se è così, allora è certamente un candidato per essere un altro AR. Se, d'altra parte, questi altri Attribute s sono riferiti (e allegati al Property AR) per il loro valore / nome, allora forse non meritano di essere i loro propri AR.
Mi sembra che tu stia introducendo una complessità inutile classificando separatamente un singolo tipo di proprietà, in particolare b / c non conosci nemmeno il vero tipo fino a quando il (numero di) proprietà è allegato.
C'è un problema che rappresenta tutti i tipi di proprietà come alcuni tipi di proprietà multiple con una collezione che ha zero o più proprietà? Ciò vale anche per la buona domanda che @ConstantinGalbenu chiede in merito al comportamento differenziato. Ora, sicuramente una proprietà senza attributi e con un attributo e più attributi può avere comportamenti diversi, ma in che misura e hai bisogno di ereditarietà per supportare tell che non chiedi consumando i chiamanti.
Non sono sicuro che sia così, anche se la tua domanda suggerisce che le entità possono passare da nessun attributo a singolo attributo a più attributi. Se questo è il caso, l'uso di una gerarchia di classi per questo mi sembra controindicato (ma può ancora essere fatto, per essere sicuro, se si vuole distruggere e ricostruire oggetti di nuovo tipo con la stessa identità). La relazione is-a deve essere stabile e se gli attributi possono venire (e forse andare) che non dovrebbero far parte della relazione is-a - è solo composizione.
Ma torniamo all'aspetto DDD: DDD non richiede AR separati per i sottotipi, in quanto non ci dice come implementare la struttura delle classi. Il concetto AR di DDD si occupa di riferimenti e identità visti dai client esterni al contesto limitato.