docs: improved readability

docs/28.04.2024-adr-secondary_key_based_storage.md

@@ -14,7 +14,7 @@ This ADR explores a couple of approaches to enable secondary key-based object in
 
 ### Infer the secondary key from the object instance to store
 
-The idea consists of inferring the secondary key from the definition of the Mongoose schema related to the type of the object instance to store. The target secondary key could be identified by a new property (e.g., `sk`) included in one or more schema field definitions, since Mongoose `Schema` does not currently include it in its API. Here is an example of how the schema of a `Book` domain object could look like:
+The idea consists of inferring the secondary key from the definition of the Mongoose schema related to the type of the object instance to store. The target secondary key could be identified by a new property (e.g., `sk`) included in one or more schema field definitions, since the Mongoose `Schema` type does not currently include it in its API. Here is an example of how the schema of a `Book` domain object could look like:
 
 ```
 export const BookSchema: Schema<Book> = extendSchema(
@@ -27,9 +27,9 @@ export const BookSchema: Schema<Book> = extendSchema(
 );
 ```
 
-As a side note, one may think that the schema `unique` property is ideal for this purpose, but Mongoose schemas may specify multiple `unique` fields or they may only be specified for some domain subtype schemas, just to mention a couple of possible issues. Thus, the `unique` property is not ideal for the inference of secondary keys.
+As a side note, one may think that the schema `unique` property is ideal for this purpose, but Mongoose schemas may specify multiple unique fields or they may only be specified for some domain subtype schemas, just to mention a couple of possible issues. Thus, the `unique` property is not ideal for the inference of secondary keys.
 
-The advantage of this approach is simplicity; it requires some modification on the `save` operation implementation details and leveraging Mongoose `Schema` to support secondary key specification while the signature and return type of `save` remain as is.
+The advantage of this approach is simplicity; it requires some modification on the `save` operation implementation details and leveraging Mongoose the `Schema` type to support secondary key specification while the signature and return type of `save` remain as is.
 
 However, and as mentioned earlier, the `save` operation must support the update of partial contents of a domain object. This means that the given object can be of type `Object`, making it impossible to infer its domain object type. This, in turn, makes it impossible to determine the schema associated to the type. Hence, it is also impossible to identify those schema fields acting as secondary keys. This approach is only possible to store instances of a given domain object type that specify valid (although not necessarily complete) contents.
 
@@ -56,15 +56,15 @@ None of the two explored approaches is good enough to enable secondary key-based
 
 ```
 save(entity, secondaryKeyValues) {
-	const document = this.entityModel.findOne(<secondary key value-based criteria>);
-	if (document) { // Mongoose-based entity update
-		document.set(entity);
-		const updatedDocument = document.save();
-		return this.instantiateFrom(updatedDocument);
-	}
-	else { // Monguito-based entity insertion
-		return this.insert(entity);
-	}
+  const document = this.entityModel.findOne(<secondary key value-based criteria>);
+  if (document) { // Mongoose-based entity update
+    document.set(entity);
+    const updatedDocument = document.save();
+    return this.instantiateFrom(updatedDocument);
+  }
+  else { // Monguito-based entity insertion
+    return this.insert(entity);
+  }
 }
 ```