docs: updated Architecture documentation

docs/ARCHITECTURE.md

@@ -2,4 +2,17 @@
 
 ## Application
 
+### Use Cases
+The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
+
+We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns.
+
+We do, however, expect that changes to the operation of the application will affect the use-cases and therefore the software in this layer. If the details of a use-case change, then some code in this layer will certainly be affected.
+
+### Framework
+This layer is where all the I/O components go: the UI, database, frameworks, devices, etc. It's the most volatile layer. Since these components are so likely to change, they are kept as far away, from the more stable domain layers, as possible. Because they are kept separate, it's relatively easy make changes or swap one component for another.
+
 ## Spec
+The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
+
+An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.