Diagram tying the product requirements + decisions together

Wim Leers → credited ctrlADel → .

1. Mermaid diagram *.md files being out of sync are caught: https://git.drupalcode.org/project/experience_builder/-/jobs/1864229
2. Syntax errors are caught: https://git.drupalcode.org/project/experience_builder/-/jobs/1864354
3. That was for the single-diagram case, now it's been hardened to work for the multiple diagrams it'll generate.
4. Copy/pasting that file into https://structurizr.com/dsl, editing+previewing it there and then copying it back is a pretty good experience — far less fiddly than using OmniGraffle! 😄

⇒ https://git.drupalcode.org/project/experience_builder/-/merge_requests/60 is ready.

Going ahead and merging this so that I can hit the ground running on Monday 🚢

I wonder if we need the overhead of the DSL?
Gitlab supports mermaid and we can edit them direct on mermaid.live

FYI: initial diagram of the data model as currently partially implemented and the direction we’ve been going in: https://git.drupalcode.org/issue/experience_builder-3454677/-/blob/34546...

P.S.: that's a "direct" Mermaid diagram, which I think will please @larowlan 🤓

@larowlan one of the benefits of using structurizr's DSL from is that it's really easy to generate and keep in sync smaller diagrams that are easier to digest and if you put the code in the previewer at https://structurizr.com/dsl it's really easy to zoom in/out on specific areas. I'm not particularly attached to structurizr but am a fan of the concepts behind c4 that encourage diagramming systems at multiple levels of detail so people can more easily onboard.

@wimleers I know these diagrams are early drafts but it looks like XB.dsl is missing Senior Developers as a person and Code Defined components that live alongside Config Defined components.

#9: Done.

The current MR is a decent starting point for capturing both what already exists and what's being discussed in all other "early phase" issues → , except for:

• 🌱 [META] Real-time preview: supporting back-end infrastructure Needs work
• 🌱 [PP-1] Create components for a default design system Postponed

In general, the docs in MR61 are focused on the server-side part of XB. The client-side part of XB will follow later and depends on strong design direction existing there first. Finally: the server side is also where most of the Drupal community's interests & concerns lie, so getting that off the ground first should happen first.

Going ahead and merging to allow referencing the diagrams in the various issues.

First issue that builds on top of the two MRs merged here so far: #3455629-12: [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model → .

Merging @jessebaker's diagram of the current state of the React front end/client — it's subject to change just like everything else, but it'll help onboard new contributors — and keep existing contributors on the same page.

Now I just need to win the fight with GitLab to actually merge this MR — it's refusing to merge for mysterious reasons …

The C4 diagram is still accurate.

Since then,

1. 📌 Document the current JSON-based data model, and describe in an ADR Active landed
2. 📌 Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed landed and added ADR #2 (and updated docs/diagrams/data-model.md)
3. 📌 Clarify the "shape matching" bits: namespaces, `CODEOWNERS` and as issue queue component Fixed landed
4. 📌 Document the current component discovery + SDC criteria, and describe in an ADR Active is about to land and will add ADR #3

I think that's sufficient for us to be able to consider this :)

Automatically closed - issue fixed for 2 weeks with no activity.