Vlákno názorů k článku Cibulová architektura aneb jak nepřipravovat špagety od Vít Šesták - > Vrstvu persistence si v cibulové architektuře můžete...

> Vrstvu persistence si v cibulové architektuře můžete představit jako plugin do vrstvy application.

Já s touto představou mám trochu problém, protože pojem plugin znám já (i Wikipedia: https://en.m.wikipedia.org/wiki/Plug-in_(computing) ) jako něco, co přidává funkčnost nějakému existujícímu [a tedy samostatně funkčnímu] programu. Jenže program bez perzistence typicky není samostatně funkční. Šlo by o tom debatovat u textového editoru, kde mohu psát text, ale uložit to musím přes Ctrl+C a Ctrl+V někam jinam. Snad úplně bez debat to je u adresáře kontaktů, kde bez perzistence nebudou fungovat ani tak základní věci jako hledání kontaktů.

Navíc u toho textového editoru bych si plugin pro perzistenci představoval asi jako něco, co by mohlo řešit i kus uživatelského rozhraní. Mohlo by to řešit dialog pro ukládání a načítání (a podle pluginu bychom mohli mít třeba podporu labelů nebo různé druhy hledání). Také by takový plugin mohl mít GUI pro řešení případných konfliktů, když více uživatelů upravuje jeden dokument. Toto ale příliš nesedí s tím, že prezentace je někde jinde.

Dobrý den,

Plugin přidává funkčnost existujícímu programu. Cibulová architektura může být použita i bez persistence, ovšem tomu musí odpovídat i zadání aplikace. Pokud je nelogické, aby program fungoval bez persistence, tak je očekáváno, že vrstva persistence bude existovat.
Vyobrazení pomocí pluginu mělo podpořit představu čtenáře o tom, že je možné tuto vrstvu vyměnit. V jádře aplikace budeme držet předpis, jakým chceme s daty pracovat a v jakém tvaru ukládat, aktualizovat, mazat či číst. To, jaká databáze či technologie je použita na uložení stavu dat, by nás v jádře aplikace nemělo zajímat.
Pokud chcete aby plugin s vaší aplikací fungoval, potřebujete naimplementovat nějaký komunikační kanál. V našem případě by to byly například rozhraní návrhového vzoru repository.

Jestliže pojem „plugin“ měl zlepšit představu čtenáře, minimálně za mě se to moc nepovedlo. Spíš to ve mě vzbudilo pochyby, jestli to chápu správně. Možná by se více hodil pojem „modul“.

Použití výrazu "plug-in" je možná trochu nešťastný (on obecně je ten článek psaný tak nějak netechnicky), nicméně s myšlenkou se nedá než souhlasit.

Je možné napsat komponentu tak, její hlavní modul obsahuje jen doménu a aplikační logiku + rozhraní pro persistenci a následně existují 4 moduly s různými implementacemi v různých technologiích (ORM framework, čisté sql, mongo, textový soubor).

Vy si následně vyberete, kterou dvojici modulů přidáte do svého projektu, dle vlastních potřeb.

Článek je opravdu pojmut méně technicky. Chtěl jsem představit myšlenku a poskytnout popřípadě užitečné odkazy pro detailnější zkoumání.
Každopádně naprosto souhlasím. Jak říkáte, 4 moduly a jejich implementace bych udržoval ve společných knihovnách a použil tu, která je vhodná pro danou doménu nejvíce. Zde se přibližujeme už velmi k architektuře Microservices + DDD, kterou nyní vyvíjíme.