core: doctrine constants and introspection domain models#106
Conversation
absoludity
left a comment
absoludity
left a comment
There was a problem hiding this comment.
I'm just reviewing the code since it is mostly from #56 , and part of the point here is to actually understand and review the code (for me). Keen to understand the points below.
| @@ -0,0 +1,12 @@ | |||
| """Domain models for the shared (core) accelerator. | |||
There was a problem hiding this comment.
This docstring is copied from the original #56 , but some of it is unclear to me. How are these entities domain models for the shared (core) accelerator? What accelerator?
I would have thought they are domain models for the core doctrine and policy tests?
| @@ -0,0 +1,12 @@ | |||
| """Domain models for the shared (core) accelerator. | |||
|
|
|||
| These models represent the foundational code concepts that julee is built on. | |||
There was a problem hiding this comment.
| These models represent the foundational code concepts that julee is built on. | |
| These models represent the foundational code concepts that julee is built on and that are verified by the doctrine tests. |
| @@ -0,0 +1,134 @@ | |||
| """BoundedContext domain model. | |||
|
|
|||
| Represents a bounded context (accelerator) as a code structure, independent | |||
There was a problem hiding this comment.
| Represents a bounded context (accelerator) as a code structure, independent | |
| Represents a bounded context as a code structure, independent |
I don't think a bounded context is an accelerator?
| These markers reflect the Clean Architecture layers present in a | ||
| bounded context. Supports both flattened structure ({bc}/entities/) | ||
| and legacy structure ({bc}/domain/models/). |
There was a problem hiding this comment.
Why legacy structure? Is this an artifact of historical changes in the original #56?
Also, I don't see any mention of this structure below - it's just boolean properties and a single calculated property?
| # run_next() pattern attributes | ||
| has_run_next_method: bool = False | ||
| run_next_has_workflow_decorator: bool = False | ||
| run_calls_run_next: bool = False | ||
| sets_dispatches_on_response: bool = False |
There was a problem hiding this comment.
Wasn't the "run_next" a old pattern in julee that we used before the predecessor to handlers? If so, I assume we can remove this and related code?
1 participant
First part of #56 as reviewable PRs - doctrine tests for use cases. The series of 4 PRs allows running doctrine tests for use-cases and is just over 2k lines, so I've split it into 4 PRs - this is the first. Some of the code is from #56, but I've made changes in places. I've also reviewed this myself to add questions about things that aren't clear to me in the code imported from #56. Agent description below:
Doctrine tests need to introspect a codebase and reason about what they find.
Before any scanning or testing can happen, we need a shared vocabulary: what
is a bounded context, a use case, a request, a response, a pipeline?
This PR establishes that vocabulary as typed Pydantic models and named
constants. Nothing here does anything yet — it just defines the concepts
that the scanner (next PR) and the tests (final PR) will use.
The naming constants in `doctrine_constants.py` are load-bearing: they are
the single source of truth for suffix conventions (`UseCase`, `Request`,
`Response`) and directory layout (`entities/`, `use_cases/`, etc.). The
doctrine tests enforce these by scanning for them — changing a constant here
will immediately surface violations across the whole codebase.
Part of a stack