feat: Version 1.0 of the request-derived context #1
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| This means the context must be derived from the request itself. | ||
| - **Early Context Requirements** <br/> | ||
| Core decisions at both the application and domain level will often depend on context, which means it must be | ||
| resolved early on, so the request can be processed correctly. |
There was a problem hiding this comment.
"resolved" is a funny word, because it could be understood to mean completely understood; whereas multi-request context requires that it isn't finalised. Think "Cookes are resolved" which means they're fully decoded, but does not mean they are appended to the response.
Not sure what the better wording is, though. Context is recognised? Loaded?
There was a problem hiding this comment.
"resolved" is a funny word, because it could be understood to mean completely understood; whereas multi-request context requires that it isn't finalised. Think "Cookes are resolved" which means they're fully decoded, but does not mean they are appended to the response.
Not sure what the better wording is, though. Context is recognised? Loaded?
I've changed "must" to "may" locally, to address this specific concern. The context can be resolved at any point, but in some cases it may need to be resolved early.
There was a problem hiding this comment.
- Early Context Requirements
Core decisions at both the application and domain level will often depend on context, which means it may be
resolved early on, so the request can be processed correctly.
The pattern must allow for both early and late resolution of context, whether eager or lazy.
There was a problem hiding this comment.
Pull Request Overview
This PR introduces version 1.0 of the request-derived context pattern documentation by clarifying and standardizing the approach to extracting contextual information from HTTP requests.
- Updated the intent and problem sections for clearer, more comprehensive descriptions.
- Expanded the solution section with a detailed breakdown of pattern components (extractor, resolver, and mentions of store and manager).
Comments suppressed due to low confidence (1)
PATTERN.md:93
- Consider adding brief explanations for the 'store' and 'manager' components to complete the architectural overview.
The solution is to separate the process into four distinct components, an extractor, a resolver, a store, and a manager.
The first version of the request-derived context pattern.
The pattern defines a consistent and reusable structure for identifying the context of a HTTP request, such as the current user, tenant, locale, language, session, or any combination of the above.