A.1.1:4.6 - Recover DDD context mapping by direct object
Start with three questions: what reusable way of mapping was used, what work actually happened, and what claim-bearing product resulted? Identify that product under C.2.1. Call the same episteme a view only after it passes one exact E.17.0 viewpoint-conformance test. Keep the relation structure it describes and every diagram, page, or publication separate.
| DDD source term or use | FPF object |
|---|---|
Bounded Context when the joint model-use organization changes an engineering move | BoundedModelUseStructure, governed as a U.Structure |
| subsystem at the boundary | the exact existing U.System under its direct pattern |
| work performed by a team system at the boundary | one exact dated Work individual independently admitted under A.15.1 after the exact actual performer System is recovered through A.13; add the same obtaining assignment occurrence and F.6 performedUnderAssignment relation only when this account expressly represents precise assignment-bound attribution |
| code base or database schema at the boundary | first classify the exact referent: claim-bearing code or schema content is a C.2.1 episteme; a repository, file, publication form, or carrier stays under its direct representation, publication, or carrier pattern; a deployed database or software organization stays a U.System or selected U.Structure under its subject pattern; the source phrase supplies no common kind |
| bounded-context boundary description | U.Episteme whose C.2.1 EntityOfConcern reference designates the exact referent named by its claims |
Context Mapping as a reusable way of doing | U.Method; any work plan, performed mapping work, evaluation work, and evaluation result remain separate |
| relations among several bounded contexts | conditional A.22 membership for one already identified U.Structure, available only after independently governed exact obtaining crossings are selected among several bounded model-use structures and all four A.22 base discriminators are established; A.22 retains a local pending label for this rule but F.17 publishes no public cross-structure term |
candidate product called Context Map | one independently identified C.2.1 episteme whose EntityOfConcern is the proposed or described crossing organization while a direct crossing governor or A.22 base identity is missing; only after both are established may a corresponding episteme designate the exact structure admitted by A.22’s conditional cross-structure rule; either episteme has dependent U.View membership only when exact E.17.0 EpistemeViewpointConformanceRelation obtains |
| visual or interactive expression and availability of an already admitted Context Map view | any C.29 representation and correspondence, rendering work, publication occurrence, publication form, and U.PresentationCarrier remain separate under their direct patterns |
Code/schema split. Start from the exact claim, not the source phrase. Claim-bearing source-code or schema content such as PressControllerCode-18 is a C.2.1 episteme with an exact EntityOfConcern and effective scheme. A repository, file, publication form, or presentation carrier that bears that content remains under its direct representation/publication/carrier pattern. A deployed controller, database, or software organization remains an actual system or selected structure under its subject pattern. The phrase code base or database schema grants none of those identities and never supplies one universal kind.
Positive case: the fixed claims expressed by PressControllerCode-18 participate as the expression episteme in ModelExpressionCoherenceRelation. Near misses: PressControllerRepository-2 is only the repository or carrier being referred to, and DeployedPressDatabase-4 is the deployed database system or structure. Neither near miss may fill an episteme participant merely because source practice calls it a code base or schema.
This dispatch table is a reading aid for selecting the governing FPF object and pattern. Only that direct pattern supplies object identity, relation obtaining, or dependent-kind membership. If a separately current claim says that the candidate episteme first existed through the performed mapping Work, apply A.15.PROD only to that exact local inception claim. If an earlier episteme participates as source, use C.2.P to recover the exact source expression and route the source-use relation to its direct governor. Evaluation Work and any result episteme remain separate. None of those facts, and no product name, representation, rendering, publication occurrence, form, or carrier, grants U.View membership.
FPF Map remains the mapping-method head for mapping subjects to coordinates in a declared Space. The quoted DDD product name stays a retrieval cue; by itself it grants neither dependent U.View membership, the FPF Map reading, nor identity with the structure.
BoundedModelUseStructure and A.22’s conditional cross-structure rule concern different structures. First identify every bounded model-use structure from its own model, admitted holons, three direct relation families—including each applicability occurrence’s exact U.ClaimScope participant—exact applied constraint claims, and named frame. A scope or membership result is not copied into the constraint discriminator. Only then may a distinct A.22 structure select several such endpoints and independently governed obtaining crossings among them. Until those crossing occurrences and all four A.22 base discriminators exist, no member of that conditional specialization is asserted and its A.22-local label remains pending. Maintenance Work remains separate from both structures. A candidate context-mapping episteme may carry claims about a proposed crossing organization without designating an exact structure. Once the direct crossing and A.22 identity exist, a corresponding C.2.1 episteme may designate that exact cross-structure and its participants. Only an explicit C.29 representation may show the structure or proposal; the episteme is a U.View only after exact E.17.0 conformance obtains.