Deep research: Evidence datového modelu, aplikační logiky a field-level usage v Obsidianu

Autor: Hermes Agent
Datum: 2026-05-17
Typ: deep research
Scope: Obsidian-native přístup + Dataview-centric model + relationship pluginy + rollout pro CRM / Dataverse dokumentaci
Vstupní task: [[Task: Výzkum evidence propojení datového modelu a aplikační logiky v Obsidianu]]

Executive summary

Pokud chceš v Obsidianu spolehlivě dohledat, kde všude se používá konkrétní pole a co rozbije jeho změna, jako default doporučuju tento model:

Source of truth = Markdown notes
Struktura = hybridní knowledge model
1 note = 1 entita
1 note = 1 executable asset / logický objekt
1 note = 1 field jen pro critical / shared / integration-heavy pole
low-value fieldy držet jen jako tabulku uvnitř entity
Typed metadata = YAML / Properties
Dotazování = Dataview
Vztahy = explicitní wikilinky + typed relation fields
Vizualizace = Canvas / Excalidraw / Juggl pouze jako view layer, ne source of truth
Rozhodnutí = ADR notes

Jednověté doporučení

Pro CRM / Dataverse projekty zaveď hybridní model “Entity + Critical Field + Asset + ADR”, kde field-level traceability stojí na typed metadata (reads, writes, validates, derives) a na Dataview query vrstvách.

1. Co přesně řešíme

Cílem není jen popsat data model, ale umožnit odpovědět na otázky typu:

Kde všude se používá contact.firstname?
Které pluginy ho čtou?
Které flow / integrace ho zapisují?
Jaké validace nad ním existují?
Z čeho je odvozováno jiné pole?
Jaký bude blast radius změny typu, názvu nebo semantics pole?

To znamená, že musíš evidovat 4 vrstvy zároveň:

Structural model – entity, pole, datové typy, relace
Behavioral model – kdo co čte, zapisuje, validuje, odvozuje
Decision model – proč to tak je
Impact / traceability model – co je upstream/downstream

2. Variants comparison

2.1 Porovnání přístupů

Varianta	Jak funguje	Výhody	Slabiny	Verdict
1. Čistě wikilinkový model	notes propojené jen odkazy v textu	jednoduchý start, nízké tření	špatná queryovatelnost, slabé typed relations, rychle se rozpadá	dobré na začátek, ne jako standard
2. Wikilinky + YAML frontmatter	odkazy + metadata ve frontmatter	výrazně lepší struktura, strojově čitelné	pořád vyžaduje disciplínu a konvence	minimum, které dává smysl
3. YAML + Dataview-centric	metadata jsou primární zdroj query/reportů	nejlepší poměr síla / jednoduchost / auditovatelnost	složitější návrh schématu, část advanced dotazů končí v DataviewJS	nejlepší default
4. Graph/relationship plugin-centric	vztahy řeší hlavně specializovaný plugin	silná vizualizace, zajímavé typed views	plugin risk, složitější onboarding, často slabší jako source of truth	vhodné jen jako doplněk
5. Hybridní doporučený model	notes + metadata + Dataview + volitelná vizualizace	nejlepší traceability i maintainability	chce zavést standard a review proces	doporučený standard

2.2 Rozhodnutí

Default zvolit variantu 5:

notes jako source of truth,
YAML / Properties jako typed metadata,
Dataview pro query,
wikilinky pro navigaci a backlinks,
Canvas / Excalidraw / Juggl jen pro vysvětlení a vizuální mapy.

3. Doporučený target operating model

3.1 Typy notes

Zaveď pevné note types:

Type	Účel	Povinné?	Poznámka
`entity`	business / Dataverse tabulka	ano	1 note = 1 entita
`field`	critical pole	ano pro critical fieldy	low-value fieldy nemusí mít vlastní note
`asset`	plugin, flow, integration, script, report, form logic	ano	to je hlavní nosič behavioral traceability
`rule`	business rule / validation / derivation	doporučeno	může být i podtyp `asset`, ale raději oddělit pokud je hodně pravidel
`decision`	ADR / design decision	ano pro významné změny	vysvětluje proč
`system`	externí nebo interní systém	doporučeno	CRM, ERP, DWH, portal
`concept`	business term / ubiquitous language	volitelné	pomáhá proti pojmovému driftu
`diagram`	curated arch view	volitelné	pouze vizualizační vrstva

3.2 Kdy udělat 1 note = 1 field

Udělat samostatný field note, pokud pole je:

business-critical,
používáno ve více pluginech / flow / reportech,
součást integrace,
validováno nebo odvozováno,
PII / compliance relevantní,
identifier / lookup / canonical value,
často diskutované při impact analysis.

Nedělat samostatný field note, pokud pole je:

triviální display atribut,
lokální pomocné metadata,
nepoužívané v logice,
bez business dopadu.

Praktické pravidlo

Tier A fields → vlastní note
Tier B fields → jen katalogová tabulka v entity note

To je klíčové, jinak se vault utopí v maintenance costu.

4. Doporučená složková struktura vaultu

00-home/
  Architecture Hub.md
  Traceability Dashboard.md

01-domains/
  Sales/
  Service/
  Finance/

10-entities/
  Contact.md
  Account.md
  Opportunity.md

11-fields/
  Contact/
    contact.firstname.md
    contact.emailaddress1.md
  Account/
    account.accountnumber.md
    account.creditlimit.md

20-assets/
  Plugins/
    Plugin - Validate Contact First Name.md
    Plugin - Sync Contact To ERP.md
  Flows/
    Flow - Welcome Email.md
  Reports/
    Report - Customer Completeness.md
  Forms/
    Form Script - Contact OnLoad.md
  Integrations/
    Integration - Dataverse to ERP Contact Sync.md

30-rules/
  Rule - Contact name required for B2C.md
  Rule - Credit score derivation.md

40-systems/
  Dataverse.md
  ERP.md
  DWH.md
  Portal.md

50-decisions/
  ADR-001-contact-name-model.md
  ADR-002-creditlimit-source-of-truth.md

60-queries/
  Query - Critical fields by entity.md
  Query - Assets using field.md
  Query - Downstream impact.md

70-diagrams/
  Contact lifecycle.canvas
  CRM integration landscape.excalidraw.md

80-templates/
  Entity Template.md
  Field Template.md
  Asset Template.md
  Rule Template.md
  ADR Template.md

Proč takto

entities a fields oddělují structural model,
assets a rules oddělují behavioral model,
decisions drží rationale,
queries a diagrams jsou views nad modelem,
složky nejsou source of truth samy o sobě; source of truth je metadata + links.

5. Metadata standard

5.1 Společné minimum pro všechny notes

id: entity-contact
kind: entity
status: active
owner: crm-team
last_verified: 2026-05-17
verification_source: code-review
confidence: high
aliases: []
tags: []

Doporučení: - id drž stabilní a strojově čitelný, - kind je povinný diskriminátor, - last_verified a confidence pomáhají odhalovat zastaralé notes.

5.2 Entity template

id: entity-contact
kind: entity
display_name: Contact
logical_name: contact
domain: sales
system_of_record: [[Dataverse]]
owner: crm-team
status: active
criticality: high
fields:
  - [[contact.firstname]]
  - [[contact.lastname]]
  - [[contact.emailaddress1]]
key_fields:
  - [[contact.emailaddress1]]
related_entities:
  - [[Account]]
used_by_assets:
  - [[Plugin - Validate Contact First Name]]
  - [[Integration - Dataverse to ERP Contact Sync]]
decisions:
  - [[ADR-001-contact-name-model]]
last_verified: 2026-05-17
verification_source: schema-review
confidence: high

5.3 Field template

id: field-contact-firstname
kind: field
entity: [[Contact]]
logical_name: contact.firstname
display_name: First Name
data_type: string
required: false
max_length: 100
pii: true
classification: personal-data
source_of_truth: [[Dataverse]]
criticality: medium
status: active
reads:
  - [[Plugin - Validate Contact First Name]]
  - [[Integration - Dataverse to ERP Contact Sync]]
writes:
  - [[Dataverse UI]]
  - [[Integration - Portal Contact Capture]]
validates:
  - [[Rule - Contact first name sanitization]]
derives: []
derived_from: []
impacts:
  - [[ERP]]
  - [[Welcome Email Personalization]]
decisions:
  - [[ADR-001-contact-name-model]]
last_verified: 2026-05-17
verification_source: code-review
confidence: medium

5.4 Asset template

Použij pro plugin, flow, integration, report, script nebo form logic.

id: asset-plugin-validate-contact-first-name
kind: asset
asset_type: plugin
layer: server
system: [[Dataverse]]
trigger:
  message: update
  stage: pre-operation
  entity: [[Contact]]
owner: crm-team
status: active
repo: crm-plugins
path: src/Plugins/ValidateContactFirstName.cs
reads:
  - [[contact.firstname]]
  - [[contact.lastname]]
writes: []
validates:
  - [[contact.firstname]]
derives: []
depends_on:
  - [[Rule - Contact first name sanitization]]
affects_entities:
  - [[Contact]]
decisions:
  - [[ADR-001-contact-name-model]]
last_verified: 2026-05-17
verification_source: code-review
confidence: high

5.5 Rule template

id: rule-contact-first-name-sanitization
kind: rule
rule_type: validation
owner: crm-team
status: active
reads:
  - [[contact.firstname]]
writes: []
validates:
  - [[contact.firstname]]
implemented_by:
  - [[Plugin - Validate Contact First Name]]
affects_entities:
  - [[Contact]]
severity: medium
last_verified: 2026-05-17
verification_source: code-review
confidence: high

5.6 ADR template

id: adr-001
kind: decision
status: accepted
date: 2026-05-17
decides_for:
  - [[Contact]]
  - [[contact.firstname]]
  - [[Plugin - Validate Contact First Name]]
supersedes: []
review_date: 2026-08-01

6. Linkovací strategie

6.1 Základní pravidlo

Wikilink sám o sobě nestačí.

Používej dvě vrstvy zároveň:

Wikilinks v textu – pro čitelnost a navigaci
typed linky v metadata fields – pro query a impact analysis

6.2 Doporučená taxonomie relation fields

Drž jádro malé a stabilní:

Pole	Význam
`fields`	entity obsahuje tato pole
`reads`	asset / rule čte tato pole
`writes`	asset / integration zapisuje tato pole
`validates`	asset / rule validuje tato pole
`derives`	asset nebo rule odvozuje tato pole
`derived_from`	field je odvozen z těchto fieldů
`depends_on`	závislost na assetu, pravidlu nebo systému
`used_by_assets`	agregovaný přehled usage
`decisions`	relevantní ADR
`related_entities`	business nebo technická relace mezi entitami

6.3 Směr linkování

Doporučený směr:

Field -> Entity
Asset -> Field přes reads, writes, validates, derives
Rule -> Field
ADR -> affected objects
Entity -> key fields / related entities

Praktický důvod: - backlinks na field note pak přirozeně ukazují „kde všude se pole používá“.

7. End-to-end příklad

7.1 Entita `Contact`

Note: 10-entities/Contact.md

id: entity-contact
kind: entity
display_name: Contact
logical_name: contact
domain: sales
system_of_record: [[Dataverse]]
fields:
  - [[contact.firstname]]
  - [[contact.lastname]]
  - [[contact.emailaddress1]]
used_by_assets:
  - [[Plugin - Validate Contact First Name]]
  - [[Integration - Dataverse to ERP Contact Sync]]
  - [[Flow - Welcome Email Personalization]]
status: active

7.2 Pole `contact.firstname`

Note: 11-fields/Contact/contact.firstname.md

id: field-contact-firstname
kind: field
entity: [[Contact]]
logical_name: contact.firstname
display_name: First Name
data_type: string
required: false
pii: true
reads:
  - [[Plugin - Validate Contact First Name]]
  - [[Flow - Welcome Email Personalization]]
  - [[Integration - Dataverse to ERP Contact Sync]]
writes:
  - [[Dataverse UI]]
  - [[Integration - Portal Contact Capture]]
validates:
  - [[Rule - Contact first name sanitization]]
derived_from: []
status: active

7.3 Plugin používající pole

Note: 20-assets/Plugins/Plugin - Validate Contact First Name.md

id: asset-plugin-validate-contact-first-name
kind: asset
asset_type: plugin
trigger:
  message: update
  stage: pre-operation
  entity: [[Contact]]
reads:
  - [[contact.firstname]]
writes: []
validates:
  - [[contact.firstname]]
implemented_rules:
  - [[Rule - Contact first name sanitization]]
status: active

7.4 Další dva usage příklady

Flow: Welcome Email Personalization

id: asset-flow-welcome-email
kind: asset
asset_type: flow
reads:
  - [[contact.firstname]]
  - [[contact.emailaddress1]]
writes: []
depends_on:
  - [[Mailing Platform]]
status: active

Integration: Dataverse to ERP Contact Sync

id: asset-integration-contact-sync
kind: asset
asset_type: integration
source_system: [[Dataverse]]
target_system: [[ERP]]
reads:
  - [[contact.firstname]]
  - [[contact.lastname]]
  - [[contact.emailaddress1]]
writes:
  - [[erp_contact.first_name]]
status: active

7.5 Jak pak dohledat usage pole

Pro contact.firstname chceš najít: - kdo čte, - kdo zapisuje, - kdo validuje, - kde je downstream dopad.

To řeší kombinace: - metadata přímo na field note, - backlinks, - Dataview dotazy nad reads, writes, validates, - případně DataviewJS pro širší impact chain.

8. Dataview dotazy

Pozn.: syntax se může mírně lišit podle konkrétního modelu Properties / plugin verze; níže je návrhový standard.

8.1 Všechna pole entity

TABLE logical_name AS "Pole", data_type AS "Typ", criticality AS "Kritičnost", status AS "Status"
FROM "11-fields"
WHERE kind = "field" AND entity = [[Contact]]
SORT logical_name ASC

8.2 Všechna assets používající konkrétní field

TABLE asset_type AS "Typ assetu", layer AS "Layer", status AS "Status"
FROM "20-assets"
WHERE contains(reads, [[contact.firstname]])
   OR contains(writes, [[contact.firstname]])
   OR contains(validates, [[contact.firstname]])
   OR contains(derives, [[contact.firstname]])
SORT asset_type ASC

8.3 Všechny validace nad fieldem

TABLE file.link AS "Rule / Asset", status AS "Status"
FROM ""
WHERE (kind = "rule" OR kind = "asset")
  AND contains(validates, [[contact.firstname]])
SORT file.name ASC

8.4 Downstream závislosti pole

TABLE file.link AS "Downstream objekt", kind AS "Kind", status AS "Status"
FROM ""
WHERE contains(reads, [[contact.firstname]])
   OR contains(derived_from, [[contact.firstname]])
SORT kind ASC

8.5 Critical fields bez vlastního usage pokrytí

TABLE entity AS "Entita", logical_name AS "Pole", status AS "Status"
FROM "11-fields"
WHERE kind = "field"
  AND criticality = "high"
  AND length(reads) = 0
  AND length(writes) = 0
  AND length(validates) = 0
SORT logical_name ASC

8.6 Entity s největším blast radius

TABLE length(used_by_assets) AS "Počet assetů", status AS "Status"
FROM "10-entities"
WHERE kind = "entity"
SORT length(used_by_assets) DESC

8.7 Notes ke kontrole zastaralosti

TABLE kind, owner, last_verified, confidence
FROM ""
WHERE date(today) - date(last_verified) > dur(90 days)
SORT last_verified ASC

9. Doporučené pluginy a jejich role

Níže jsou pluginy relevantní pro tento use case. GitHub stars a activity jsou ověřené k 2026-05-17 přes GitHub API.

Nástroj	Role v modelu	Proč ano	Limity	GitHub
Dataview	query engine	nejlepší poměr síla / jednoduchost / auditovatelnost	složitější transitive queries často končí v DataviewJS	8,950 ★
Excalidraw	curated diagrams	velmi silný pro architekturu a onboarding	není source of truth pro relations	6,902 ★
DB Folder	tabulková správa notes	užitečné pro katalogy a operativní editing	menší fit pro hlubokou traceability než Dataview	1,398 ★
Juggl	pokročilá graph explorace	dobré na dependency exploration	ne query backbone	800 ★
Breadcrumbs	typed-link / hierarchy navigace	užitečné tam, kde chceš explicitní traversals	vyšší adopční riziko jako core model	779 ★
Metadata Menu	governance metadata	pomáhá držet datovou disciplínu	další plugin dependency	692 ★
Canvas (core)	vizualizace	low-risk, native, vhodné pro mapy	query a traceability řeší jen nepřímo	core feature

9.1 Doporučené pořadí zavádění

Core Properties + Wikilinks
Dataview
Templates / standard metadata
Metadata Menu (pokud začne být problém s nekonzistencí polí)
Canvas nebo Excalidraw
Juggl jen pokud chceš lepší graph exploration
Breadcrumbs jen pokud víš, že potřebuješ typed traversal UX jako primary interaction model

9.2 Plugin defaulty

Default stack pro tento use case

Povinné: Dataview
Doporučené: Excalidraw nebo Canvas
Volitelné: Metadata Menu, Juggl
Opatrně / jen když je silný důvod: Breadcrumbs jako core relation layer

10. Co držet jednoduché a co už je overengineering

Držet jednoduché

malý počet note types,
6–10 stabilních relation fields,
1 note per entity,
1 note per critical asset,
1 note per critical field,
pevné templates,
pravidelná review query na stale notes.

Overengineering je

dělat note pro každý triviální field,
zavést moc pluginů naráz,
modelovat plno exotických relation types,
držet dependency info současně v textu, tabulkách, canvasech a ADR bez jasného source of truth,
spoléhat na diagramy místo metadata modelu.

11. Jak odlišit datovou strukturu, technickou implementaci, business pravidlo a impact

Používej toto rozlišení:

Vrstva	Co obsahuje	Kde žije
Datová struktura	entity, fieldy, typy, relace	`entities/`, `fields/`
Technická implementace	pluginy, flow, integrace, reporty, form scripty	`assets/`
Business pravidlo	validace, derivace, constraints	`rules/` nebo podtyp `asset`
Rozhodnutí	proč je něco navrženo takto	`decisions/`
Impact view	query a dashboards nad závislostmi	`queries/`, případně Canvas/Excalidraw

Tím se vyhneš typickému chaosu, kdy se technická implementace míchá do entity notes a časem se nedá auditovat.

12. Rollout postup

Fáze 1 – základní skeleton

Založ: - typy note templates, - složky, - naming conventions, - 3–5 základních Dataview dashboards.

Minimum done

entity, field, asset, decision templates,
naming standard,
jeden dashboard „assets using field“.

Fáze 2 – bootstrap modelu

Začni jen s: - top 10 entitami, - top 30–50 critical fieldy, - top 20 assety, - top 10 nejdůležitějšími rozhodnutími.

Nesnaž se hned pokrýt vše.

Fáze 3 – traceability coverage

Pro každý critical field doplň: - reads, - writes, - validates, - derived_from, - decisions.

Fáze 4 – governance

Zaveď Definition of Done:

žádný nový plugin / flow / integration bez asset note,
žádný nový critical field bez field note nebo aspoň katalogového řádku,
žádná významná schema změna bez update affected notes,
žádná architektonická změna bez ADR.

Fáze 5 – audit / freshness

Každý release nebo významná změna: - projít stale notes dashboard, - projít orphan fieldy, - projít critical fieldy bez usage coverage, - projít assets bez ownera nebo bez last_verified.

13. Naming conventions

Doporučené názvy notes:

Entity: Contact, Account, Opportunity
Field: contact.firstname, account.creditlimit
Asset: Plugin - Validate Contact First Name
Integration: Integration - Dataverse to ERP Contact Sync
Rule: Rule - Contact first name sanitization
ADR: ADR-001-contact-name-model

Proč

field note se dobře hledá fulltextem,
logical name zůstává stabilní,
Dataverse kontext je přirozený,
wikilinky jsou jednoznačné.

14. Rizika a limity

Riziko	Co se stane	Mitigace
Příliš detailní model	vault exploduje počtem notes	field notes jen pro critical fieldy
Nekonzistentní metadata	dotazy vrací špatné výsledky	templates + review + případně Metadata Menu
Přehnaná závislost na diagramu	vizualizace zastará, ale data ne	diagramy jen jako projection layer
Plugin lock-in	změna pluginu rozbije workflow	source of truth držet v Markdown + Properties
Chybějící review	dokumentace zestárne	`last_verified`, freshness dashboards, DoD
Duplicitní evidence	různé notes tvrdí něco jiného	single source of truth per fact

15. Default standard, který bych zavedl

Pokud bych měl navrhnout jediný standard pro tým, byl by tento:

Povinné

1 note = 1 entity
1 note = 1 plugin / flow / integration / report / form script
1 note = 1 critical field
YAML / Properties metadata s fields:
kind
status
owner
reads
writes
validates
derives
derived_from
decisions
last_verified
Dataview dashboards pro:
all fields by entity
all assets using field
downstream impact
stale notes

Doporučené

ADR notes pro významné změny
Excalidraw nebo Canvas pro onboarding a architecture maps
Metadata Menu až ve chvíli, kdy začne být problém s kvalitou metadata entry

Nedoporučené jako default

čistě graph-centric model,
čistě wiki-text bez frontmatter,
1 note pro každý trivial field,
plugin-first model bez jednoduchého markdown source of truth.

16. Praktický answer na hlavní otázky z tasku

1) Jaký knowledge model zvolit?

Hybridní model: entity + critical field + asset + decision.

2) 1 note = entity / field / plugin / use case?

entity: ano vždy,
field: ano jen pro critical fieldy,
plugin / flow / integration / report: ano vždy,
use case: volitelně, pokud je důležitý jako business scénář nebo auditní pohled.

3) Jak reprezentovat vazby?

Přes typed metadata fields (reads, writes, validates, derives, derived_from) + wikilinky v textu.

4) Jak využít wikilinky, frontmatter, Dataview a pluginy?

Wikilinky: navigace, backlinks, lidská čitelnost
Frontmatter / Properties: source of truth pro strukturované vztahy
Dataview: query vrstva a dashboards
Canvas / Excalidraw / Juggl: vizualizace a exploration
Breadcrumbs: jen pokud tým explicitně potřebuje relationship traversal UX

5) Jak to udělat udržovatelné?

malý počet note types,
critical-only field notes,
templates,
review dashboards,
DoD navázaná na změnový proces.

6) Jak oddělit datovou strukturu, implementaci, business pravidlo a impact?

Oddělené note types a složky; impact nenechávat v prose, ale generovat ho z relations.

7) Jak řešit traceability a impact analysis?

Přes explicitní relations na field-level notes a query typu „kdo čte / zapisuje / validuje / odvozuje tento field“.

17. Ověřené zdroje

Oficiální Obsidian docs

Internal links: https://help.obsidian.md/links-and-files/internal-links
Properties: https://help.obsidian.md/properties
Backlinks: https://help.obsidian.md/plugins/backlinks
Graph view: https://help.obsidian.md/plugins/graph-view
Canvas: https://help.obsidian.md/plugins/canvas

Pluginy / dokumentace

Dataview: https://github.com/blacksmithgu/obsidian-dataview
Dataview docs: https://blacksmithgu.github.io/obsidian-dataview/
Breadcrumbs: https://github.com/SkepticMystic/breadcrumbs
Juggl: https://github.com/HEmile/juggl
Excalidraw: https://github.com/zsviczian/obsidian-excalidraw-plugin
Metadata Menu: https://github.com/mdelobelle/metadatamenu
DB Folder: https://github.com/RafaelGB/obsidian-db-folder

Poznámka ke zdrojům

URL výše jsem ověřil jako dostupné.
GitHub stars / activity v tabulce pluginů jsou snapshot k 2026-05-17.

18. Final recommendation

Pro tvůj use case bych jako standard zavedl toto:

Obsidian jako lightweight architecture knowledge graph nad Markdown notes, kde entity a executable assets jsou first-class, critical fields jsou first-class selektivně a veškerá impact analysis stojí na typed metadata + Dataview dotazech.

To je nejpraktičtější kompromis mezi: - dohledatelností usage na úrovni pole, - čitelností pro architekta i vývojáře, - rozumnou mírou manuální práce, - a udržitelností v čase.