ADR 002: Doctrine Test Architecture#75
Conversation
| | **Bounded Context** | What constitutes a valid bounded context (domain/models or domain/use_cases required) | | ||
| | **Repository Protocol** | Repository interfaces live in domain/, implementations in infrastructure/ | | ||
| | **Service Protocol** | Service interfaces live in domain/, implementations in infrastructure/ | | ||
| | **Use Case** | Business logic lives in use_cases/, has execute() method taking request/response objects | |
There was a problem hiding this comment.
It's not clear to me yet (but will probably become clear later) what the request/response objects are... by name they sound like http request/response, but as this is in the domain/use_cases I'm guessing it's something else.
There was a problem hiding this comment.
Ah, yes but no but sort-of.
Requests and responses are the contract between the usecase and the things that invoke it. They are not specifically coupled to the domain layer (usecase internals), they are the "public face" of the domain-layer interactions. FastAPI just so happens to thinly wrap them into HTTP API, but the temporal worker doesn't (for example). entities are the language of the contract with services and repositories, requests/responses are the language of contracts with usecases - different layer.
There was a problem hiding this comment.
for example, requests and responses might have semantics like "pagination" that are valid concepts for the things that invoke usecases, but are not part of the domain model (what's a page?).
|
|
||
| - The test docstring IS the rule statement | ||
| - The test body IS the enforcement | ||
| - There is no drift because they are the same artifact |
There was a problem hiding this comment.
Not sure the distinction is that clear for me... it's more like the documentation is now in the same place as the enforcement, so it's less likely to diverge (but the same divergence is possible). I mean, I don't think you're running the docstring itself as a test artifact here, right?
Still, +1 for having tests as doctrine - I think it's great having the documentation defined right with the test, rather than elsewhere.
There was a problem hiding this comment.
sure, if the test docstring says "zig" and the test implementation does "zag", we will have drift. But single responsibility principle: that would be a bad test.
| ### Positive | ||
|
|
||
| 1. **Architectural compliance is verifiable**: Run pytest to check any solution | ||
| 2. **Single source of truth**: Rules cannot diverge from enforcement |
There was a problem hiding this comment.
Yes - I like that it's the doctrine in the framework that can be applied to other directories too.
|
|
||
| Write architecture rules in markdown, trust developers to follow them. | ||
|
|
||
| **Rejected**: Rules drift from reality. No automated verification. |
There was a problem hiding this comment.
Yep, it already did drift very fast when it's not in context, especially so when working with generative AI.
There was a problem hiding this comment.
👍 exactly, it's not just human developers that need to be kept on the rails.
Co-authored-by: Michael Nelson <absoludity@gmail.com>
2 participants
Summary
Cherry-picks ADR 002 from the super-branch (PR #56).
Documents the "tests ARE the doctrine" pattern:
Related
Closes #67
Cherry-picked from PR #56
Test plan