Issue 131: increase adaptability

CONTRIBUTING.md

@@ -10,19 +10,40 @@ The concept flow through the code is single threaded down a stack. What this tra
 
 What happens if new code cannot fit into the current concept flow? A refactoring of the concept flow will need to take place and all existing classes will have to be updated to the new structure. This should be resolved before any code changes take place.
 
-Lastly, the code is divided into packages that very roughly group the functionality. It is not well defined and therefore much of the code is smeared about and any clean up of the smearing is welcome - always. Below is a rough definition for each package:
-
-gov.nasa.pds.api.
-
-model.xml - strictly autogenerated code by swagger from model/swagger.yml
-registry - base package that contains interfaces to break circular dependencies and spring-boot content.
-registry.business - supposed to be the PDS specific stuff but it is much more of a hodgepodge at this time.
-registry.configuration - AWS, spring-boot, and swagger configuration information
-registry.controllers - where the user request is bottled into a UserContext or should be but it currently has a lot of business loging in it.
-registry.exceptions - all locally defined exceptions
-registry.lexer - strictly autogenerated code by antlr
-registry.opensearch - required opensearch configuration for a connection and a collection of stuff that binds business needs with opensearch
-registry.serialize - once the business logic is done, these unit seralize them into the request output format (header Accept value).
+The overall architecture/design is the MVC. In this insteance, the controller is the transmutation of uer inputs into the interfaces necessary for the model to fullfil the request. The model represents how the PDS data is stored internally. The view is the serialized output in its appropriate format since that is what the user sees or views.
+
+Lastly, the code is divided into packages that very roughly group the functionality that reflect the MVC architecture/design. While they may not perfectly enforced currently, the implementation is moving in this direction:
+
+**gov.nasa.pds.**
+
+**model**  
+  - strictly autogenerated code by swagger from model/swagger.yml
+
+**api.registry**  
+  - base package that contains  
+    - interfaces to break circular dependencies and improve encapsulation
+    - spring-boot content.
+
+**api.registry.configuration**  
+  - AWS, spring-boot, and swagger configuration information
+
+**api.registry.controller**  
+  - *control* bidirectional transmutation between registry Java design/implementation and the swagger model (auto generated code)
+
+**api.registry.exceptions**  
+  - all locally defined exceptions
+
+**api.registry.lexer**  
+  - strictly autogenerated code by antlr
+
+**api.registry.model**  
+  - supposed to be the model of how the data is stored and organized but it is much more of a hodgepodge at this time.
+
+**api.registry.search**  
+  - required opensearch configuration for a connection and a collection of stuff that binds model needs with opensearch
+
+**api.registry.view**  
+  - once the model has found the needed data, these unit seralize them into the request output format (header Accept value) to complete the request.
 
 All of the interfaces in registry are a Context. What does context mean here. It represents the conceptual flow of information. Many users can access the same endpoint with differnt parameters. These context items hold the state for those individual requests just a context is normally used with program threading. They help separate those classes that need state from that which is purely functional help. In the case of the registry, very little state is needed and is easily represented with these interfaces.