Jak řešit přístup k cizím datům

Představte si aplikaci postavenou na následující architektuře (je to příklad ze života)

Je vám jasné, v čem je problém? (Komu dělá problém přečíst ArchiMate notaci, musí se to holt někde rychle doučit – třeba u nás, v Komixu)

Možná vás napadne ledacos, ale jedna patálie je: jakákoliv strukturální změna, kterou udělá tým B na „Table B-1“ se projeví rozbitím „View na Table B-1“. Má tedy okamžitě dopad do práce týmu A, byť daná změna je jen interní záležitostí týmu B. I když to tak možná na první pohled nevypadá, je zde porušen elementární princip, že jeden modul nepřistupuje přímo na data druhého modulu (modul zde chápeme v širší smyslu jako aplikační modul + jeho DB schéma).

Jak situaci zlepšit, ideálně bez nutnosti zásadně celou aplikaci předělat? Co takto:

Jsou zřejmé výhody?

Modul A využívá dohodnuté rozhraní (realizované jako View) vystavené modulem B a interní změny na Table B-1 si tým B může „schovat“ odpovídající úpravou View. Takže tým A takovými změnami není ovlivněn. Princip nepřistupování přímo na cizí data je zde zachován.

Ještě elegantnější řešení může být toto:

Co nám to přineslo?

Tato varianta zachovala výhody té předchozí, navíc se nemusí oproti původnímu stavu ani upravovat aplikační modul A (změna bude jen v definici View v DB schématu modulu A). Uplatňuje se také princip, že aplikační modul přistupuje pouze ke „svým“ datům (byť na úrovni DB vrstvy realizováno „odkazem“ do jiného schématu).

K daném tématu by se dalo napsat spoustu dalších úvah o výhodách/nevýhodách/důsledcích zde uvedených (a případně dalších) typů řešení. Do nich se pusťte už sami – snad vám tento článek budou dobrou inspirací.