Spesso vedo il termine Invarianti in DDD. Here Dino Esposito ne parla. Se guardo la libreria .NET, vedo una classe ValidationAttribute. Sono invarianti e regole di convalida lo stesso? Ad esempio, posso dire lo sconto del 50% è disponibile solo se il totale dell'ordine è superiore a $ 250 è un invariante?Qual è la differenza tra invarianti e regole di convalida?
O sono diversi in cui gli invarianti servono a proteggere un oggetto dall'essere non valido e la convalida consiste nel verificare la validità dell'oggetto anche dopo che ha modificato il suo stato (può essere in uno stato valido o non valido)? Nell'esempio sopra, se uso invarianti, controllo l'invariante prima di aggiornare lo sconto e, in caso di convalida, applico lo sconto del 50% e quindi controllo la validità (l'oggetto è già in stato non valido).
Vi sono tuttavia alcune persone che non considereranno alcune regole di convalida di base come invarianti di dominio poiché si tratta di regole generalmente derivate da vincoli tecnici. Ad esempio, la lunghezza massima di un indirizzo email non può essere considerata un'invarianza di business da parte di alcuni professionisti del DDD poiché l'azienda non si preoccupa della lunghezza di un messaggio di posta elettronica, ma per essere pratico deve essere impostato un vincolo tecnico (ad es. 'varchar (500)' nel DB dato che non è possibile usare 'varchar (max)' per ogni campo o la dimensione massima della riga di ogni DB verrebbe in overflow. – plalx
Pertanto, si potrebbe sostenere che 'email.length <= 500' non è un invariante e potrebbe decidere di delegare il controllo al database. Tuttavia, la maggior parte dei DB non direbbe nemmeno che la colonna è in overflow, il che potrebbe essere un argomento per far rispettare la regola all'interno del dominio. – plalx
Poiché tale differenziazione è chiara tra "invarianti" e "convalida", anche gli "invarianti" possono essere chiamati "specifiche"? Sto pensando più alla linea di test degli oggetti di dominio contro gli 'invarianti'. –