Názory k článku Cibulová architektura aneb jak nepřipravovat špagety

Programátor je člověk, jterý si myslí, že jakýkoliv problém vyřeší další mezivrstva... :)

V našem světě existuje tenká vrstva mezi DRY a YAGNI pravidly. Programátor se snaží mít kód univerznální a neopakovat se, ovšem přijde často na to, že takový kód nakonec nepotřebuje.

Specialne java programatori a jejich frameworky. Ono monty pythonovske: "Society for putting things on top of other things".

Nie, zakazdym ked budem zacinat novy projekt tak si napisem implementaciu Listu, Vectora a nejaky novy memory manager.

Jako Python programátor s tímhle nesouhlasím. Zkuste si napsat něco "enterprise" v Pythonu -- zešednete a pak nakonec sáhnete po Springu

Neviem, ale ja to poznám ako lasagne-ový kód. Aj keď cibuľa je možno lepšia..

Lasagne znám v jiném významu – kód, který se sice programátor snažil rozdělit do vrstev, ale jednotlivé vrstvy nakonec prorostly: https://en.m.wikipedia.org/wiki/Spaghetti_code#Lasagna_code

Lasagne frčali už dávno :)
https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

Budeme-li brát v úvahu i "Vícevrstvé architektury", jsou podobné principy návrhu architektury systémů známy již desítky let. Věřím, že drtivá většina studovaných programátorů se jimi řídí a již desítky let se snaží vrstvy oddělovat. V oboru jsem skoro už dvacet let. Pracuji převážně na velkých informačních systémech, které dané principy dodržují/dodržo­valy.

Zatím jsem nezažil, že by si někdo troufnul vyměnit jednu z těch vrstev v obalu té cibule s tím, že zbytek se nechá skoro beze změny. Např. výměna prezentační vrstvy ve velkém systému je skoro nemožná, hlavně proto, že prakticky je i v prezentační vrstvě spousta business logiky (např. "pokud zaškrtnu tenhle checkbox, tak schovej tyhle dvě políčka" - v informačních systémech takováhle pravidla tvoří troufnu si říct vlastně většinu všech business rules). Nebo pokud někdo napíše danou aplikaci pro konkretní databázi (např DB2), tak i kdyby jste měli všechna DML a DDL v SQL standardu, tak vám to s jinou databázi prostě fungovat nebude (respektive ono se to rozjede, ale dáte ruku do ohně za to že to funguje naprosto stejně? :)).

Z mojí zkušenosti se ke starším systémům buď začal přilepovat kód v nové technologii (např souběh dvou prezentačních vrstev) a nebo se celý systém vzal a přepsal se komplet do nových technologií. Pokud někdo někdy zažil něco jiného prosím napište níže - mám na mysli systémy velikosti řádově statisíců řádek, fungujících mnoho let.

Takže s článkem souhlasím, s vrstvením souhlasím, ale pouze pro účely snadnějšího porozumění systému jako celku. Vrstvení za účelem možné "snadné" výměny nějaké části je teorie, kterou jsem v praxi opravdu nezažil a nemyslím si že je možná.

Čím jsem starší, tím víc mám pocit, že se stačí držet SOLID principů (https://en.wikipedia.org/wiki/SOLID) nejenom v návrhu tříd, ale i v návrhu modulů či integrace systémů... zbytek tak nějak vyplyne sám...

24. 1. 2020, 08:28 editováno autorem komentáře

Bohužel podobný přístup k testování nese jistá rizika - setkal jsem se s tím, kdy výsledky testů na SQLite a MySQL nebyly shodné.

V dnešní době mi přijde jako mnohem lepší způsob používat buď kontejnery nebo cloudové služby a testovat proti reálně provozované databázi.

S SQLite můžete testy spouštět častěji, mít okamžitou zpětnou vazbu, psát jich víc. Cloudové služby můžete používat souběžně, ale nemůžete je spouštět po každé změně.

Jo, jenže proč bych je měl spouštět po každé změně? Od toho tu je právě oddělení na doménový model, infrastrukturu, kam patří repositories a aplikační vrstvu (use-cases). Když už, tak tyhle testy oproti DB nakonec pouštím na CI/CD serveru. Pokud se hrabu v doménovém modelu, vůbec mě tohle nezajímá víz pojem "Persistence ignorance"

24. 1. 2020, 16:27 editováno autorem komentáře

Na to mi ale stačí změna connection stringu v konfiguračním souboru, nemusím zasahovat do aplikace a vyměňovat nějakou vrstvu.

Nevím, co je to dobře „cashovatelná“ databáze, každopádně i takovému PostgreSQL lze spustut separátní instanci. Kdysi jsem to ubastlil bez Dockeru (předpokládalo to volný port a nainstalovanou vhodnou verzi PostgreSQL), s Dockerem to půjde ještě lépe.

Ano, pro účely integračních testů jsem tomu vypnul takové „zbytečnosti“ jako fsync [1], aby to bylo rychlejší. Pravda, takové nastavení se odlišovalo od produkce, kde je fsync důležité, ale za tu rychlost testů to stálo a i tak to poskytovalo mnohem věrnější výsledky než testování oproti SQLite.

Ono testování je vždy kompromis. Vždy chceme co nejvěrnější výsledky s co nejnižším úsilím a co nejrychlejšími testy. To někdy jde proti sobě. Mít na produkci PostgreSQL a testovat na SQLite znamená používat databázi s jinými specifiky, jinými tichými defaulty (včetně řazení) apod. V době Dockerové typicky není velký rozdíl mezi náročností rozjet SQLite a rozjet PostgreSQL, takže těžko se pro to hledá dobrý důvod. Ani ORM nemusí člověka 100% odstínit od rozdílů – na to by muselo srazit možnosti všech databází na úroveň té nejméně pokročilé.

Naproti tomu takový zakázaný fsync má celkem popsané dopady. Pokud nedojde k tvrdému vypnutí (které nás stejně nezajímá, když v takovém případě databázi zahodíme a vytvoříme novou a prázdnou), rozdíl by měl být pouze v rychlosti. To čistě teoreticky samozřejmě nějaký rozdíl může udělat (pak bychom ovšem ani nemohli použít debugger [2]), ale riziko vidím jako řádově nižší než u použití jiného RDBMS.

[1] https://www.postgresql.org/docs/9.5/non-durability.html
[2] https://en.m.wikipedia.org/wiki/Heisenbug

My s tím právě měli problémy a ne vždy bylo na první pohled zřejmé, že problém vzniká rozdílnou DB. V době kdy není problém si v dockeru pustit libovolnou databázi na lokálu mi to přijde jako zbytečný odklon od produkčního prostředí.

Podobně s tím cachováním db mezi testy - podle mého to snižuje opakovatelnost testů, protože se obecně mění vstupní podmínky (testy se pravděpodobně pouští v náhodném pořadí, občas se nějaké testy mění nebo přidávají/ubírají). A já od testů očekávám, že ověřují, že se testovaná část systému chová po změně stejně jako předtím. A k tomu potřebuji kontrolované prostředí.

Výše píšete, že nikdy nemáme testovací prostředí úplně shodné s produkčním. To je sice pravda, ale není to pro mě argument pro to se od něj cíleně vzdalovat.

Abych to shrnul: chápu důvody proč se to používá, ale v dnešní době mi to přijde překonané.

Dobrý den,

V ideálním případě je cibulová architektura vhodná k výměně jedné z vrstev. V reálném případě si dokážu představit, že výměna si bude žádat nějaké úpravy, ovšem myslím si, že použitím této architektury se vám podaří minimalizovat nutný čas programátorů k výměně. Pokud může být programátor k tomu připraven, proč tomu nejít pomocí architektury naproti?

Nesouhlasím s Vámi v tom, když tvrdíte, že "pokud zaškrtnu tenhle checkbox, tak schovej tyhle dvě políčka" je bussiness rule. Něco takového je specifikace chování UI a nemá nic společného s tím, jak bussiness zákazníka funguje.

Cibulová architektura bude i umožňovat lehčí koexistenci dvou prezentačních vrstev, kterou zmiňujete. Jelikož je přepis celé prezentační vrstvy velmi náročný na finance a čas, tak by měla architektura aplikací podporovat možné scénáře vývoje co nejlépe.

SOLID principy jsou výborné principy a Cibulová architektura je podporuje na úrovni vrstev.

Souhlasím, že se tyto principy používájí obecně už dlouho a určitě se najdou vývojáři, kteří jen neví, že se tomu takhle říká.

K té výměně:
1) Pokud máte aplikační logiku ve vnějších vrstvách, tak si o problémy přímo říkáte a není to problém architektury ale kvality implementace. Souhlasím že je to, bohužel, běžná praxe.
2) Pokud chcete něco nahrazovat, musíte přesně znát kontrakt včetně vedlejších účinků. Pak jste schopni zaručit funkčnost i po nahrazení. V praxi to samozřejmě není úplně jednoduché, pomáhá kvalitní pokrytí testy.
3) A asi nejdůležitější pro myšlenku jako takovou: nelze hodnotit jak "snadné" je nahradit konkrétní implementaci vrstvy za jinou v absolutních číslech (protože do toho hodně mluvít velikost projektu, kde zrovna Vámi zmiňované systémy jsou peklo na údržbu tak nějak z principu), ale spíš v porovnání s tím, jak složité by to bylo, kdyby byla architektura navržena a naimplementována špatně.

Má osobní zkušenost je, že důsledné dodržování podobných pravidel vede k výrazně snazší a levnější údržby projektu včetně dalšího vývoje. Přičemž výměnou vrstvy je možno rozumět i třeba migrace na novější verzi technologie, což už není operace úplně neobvyklá.

Naopak, pokud je systém opravdu velký a implementace není dostatečně kvalitní, je lepší do toho moc nesahat, přesně jak píš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.

Podle našich dlouholetých zkušeností je u klasických webových víceuživatelských aplikací základem správně navržená databáze. Databáze umožní definovat vztahy mezi objekty, pravidla pro hodnoty atributů, i pohledy na data. Navíc je v jistém smyslu "univerzální" z pohledu technologického vývoje. Správná aplikace je pak jen datově řízená záležitost nad správně postavenou databází. Většinou totiž samotná aplikace je jen způsob, jak se k datům dostat.
I pro ostatní naprosto odlišné aplikace (např. grafický editor, počítačová hra) je klíčový moment způsob ukládání dat (konvence) a práce s nimi. Když si vezmete např. počítačovou hru, ta se opírá o možnosti nějakého herního enginu - a v konečném důsledku opět skončíte u způsobu, jakým se ukládají data a jakými metodami se s takto uloženými daty následně ve vytvořeném systému pracuje.

24. 1. 2020, 09:17 editováno autorem komentáře

Dobrý den,

Tímto přístupem jste výkonostně, návrhově i technologicky velmi závislí na třetí straně jako například na Microsoft SQL Serveru. V posledních letech příchází do módy NoSQL dokumentové databáze. Jakým způsobem byste řešili přechod na jinou, modernější technologii?
Obávám se, že takové webové aplikace mají kratší životnost, než by mohly být.

U každého většího řešení budete vždycky závislý na nějaké třetí straně . Kdo říká že ne, tak nemluví pravdu. Technologie přicházejí a odcházejí, ale principy rozumného návrhu platí obecně.
Mimochodem Vámi uvedené příklady nepoužíváme, ale jádra problému se to netýká. Pokud nebudete mít rozmyšleno, co jsou data a jak s nimi budete pracovat, ja tvorba aplikace -nebo její výměna- zbytečná. Také to, zda použiji nonSQL nebo SQL (pracujeme s obojím), je vedlejší.

„U každého většího řešení budete vždycky závislý na nějaké třetí straně . Kdo říká že ne, tak nemluví pravdu.“
To nikdo nepopírá, ale je nutno si vybrat tak, aby jádro aplikace bylo v nejméně závislých technologiích s nejmenšími změnami. Je rozdíl napsat dom. model v specializovaném jazyku specializované DB, nebo použít obecný programovací jazyk, na který existuje několik IDE či překladačů a bude tady ještě za 30 let.

Dobrá, souhlasím, že sem použil nešťastný výraz. Móda na to opravdu nemá vliv. Ovšem nové databázové přístupy vznikají z nějakého důvodu. Vezměte si Elastic Search. Je to mnohem vhodnější nástroj pro fulltextové vyhledávání než relační databáze. ElasticSearch je mladý a odhaduji že před deseti lety zde nebyl. Můžeme poskytnout větší výkon aplikace, ale je ho nemožné do Vaší aplikace zakomponovat nebo je to velmi náročné a zákazník to nebude chtít zaplatit. Tím pádem aplikace "hnije"

Ale pořád budu mít daleko raději kvalitní fulltext rovnou v DB, než řešit synchronizaci dat do neprimárního ES. Bohužel kvalitních fulltextů v DB je minimum, tak nezbývá než vytvářet funkcionalitu extra pro fulltext v ES.

Když máte aplikaci s volnými závislostmi, můžete si dovolit používat a nabízet i módu.

„V posledních letech příchází do módy NoSQL dokumentové databáze. Jakým způsobem byste řešili přechod na jinou, modernější technologii?“
No jak by to řešil? Nijak, znamenalo by to všechnu obchodní logiku přepsat do nového typu DB, což samo o sobě ještě neřeší komunikaci aplikace s novou DB.

„Podle našich dlouholetých zkušeností...“
Éééé...
„...je u klasických webových víceuživatelských aplikací...“
Web je jen formou prezentace, u aplikací s jinými či více graf. rozhraními to neplatí???
„...základem správně navržená databáze.“
A je to tady - databázocentrická aplikace!
„Databáze umožní definovat vztahy mezi objekty, pravidla pro hodnoty atributů, i pohledy na data.“
To patří do doménového modelu, ne persistentní vrstvy.
„Navíc je v jistém smyslu "univerzální" z pohledu technologického vývoje.“
Bohužel není, každá DB má trochu jiné vlastnosti, v případě rozdílných typů hodně jiné vlastnosti.

Databáze je vrstvou (dle cibule částí), která se bude jistě měnit mnohem častěji než jazyk, ve kterém je napsaný dom. model, tudíž není strategické do ní umisťovat obchodní logiku. Dále: Co uděláte, když nebudete mít data uložena jen v oné jedné jediné DB, ale třeba ve 3 zcela různých? A nebo v nějakém úložišti přes HTTP? Kde bude potom umístěn dom. model s logikou? Jak bude komunikovat se zbytkem?

Taky jsem dělal v jedné velké, české, nejmenované firmě, kde bylo vše zadrátováno v DB, a to rovnou ve 3 typech RDB (to k té vaší „univerzálnosti“). Muselo se to dělat 3x, testovat se to pořádně nedalo, bylo to chybové a ukrutně pracné. O existenci dokumentových, objektových, sloupcových, časových a jiných typech DB vedení ani vývojáři netušili. Když se řešila nějaká nová vlastnost, nikdy se neřeklo „to přijde do dom. modelu sem a sem“, první bylo „do té a té tabulky dáme tenhle a tenhle sloupec“. Od konce.
Jako bonus bylo SQL v některých místech prorostlé až do prezentační vrstvy. Jakákoliv změna GUI či DB by znamenala roky úprav, což bylo nereálné, takže SW buďto nechat zabetonovaný, nebo začít úplně znovu. A to se vyplatí!

Proč zrovna tolik vrstev abstrakce? Každá vrstva přináší kód navíc, který nic nedělá, ale musí se udržovat. Rozhraní, se kterým se musí ostatní programátoři seznámit. Práce s vaší vlastní vrstvou pro ně bude komplikovanější než práce přímo s rozšířenou a dobře zdokumentovanou knihovnou, kterou znají z jiných projektů. Kvůli každé maličkosti musí přidávat funkcionalitu do každé z vrstev.

Pokud nad Vaší otázkou budu přemýšlet z hlediska mého projektu, který je použit na microservices, tak mi tolik vrstev abstrakce dávají smysl. Každá "servisa" má tuto architekturu. Každá může použít vhodnější typ databáze a přitom si zachovat velmi podobný tvar jako jiná "servisa". Programátor se zorientuje dobře v každé z nich a dokumentaci knihovny bude řešit až pokud se bude potázet s konkrétní technologií.

Pokud vytvoříme klubko špaget s použitím různých technologií a kód nebude mít řád podpořený přehlednou abstrakcí(archi­tekturou), tak i když jsou technologie dobře zdokumentovány, tak si myslím, že se časově dobereme k horšímu výsledku.

Nehledě na to, že pokud se pokusíme na takový kód napsat unit test, tak spíše selžeme.

> mého projektu

problémy, o kterých jsem psal, vyniknou hlavně při práci na cizích projektech. Moderní frameworky od psaní vlastní tzv. domain vrstvy většinou odrazují. Cílem je omezit množství kódu specifického pro vaši aplikaci na minimum. Architekturu dodává framework.

24. 1. 2020, 10:59 editováno autorem komentáře

Konkrétně užitečnost tzv. domain vrstvy je sporná.

Podívejte se na nějakou přednášku na youtube například o Domain-driven designu. Tento přístup má své důvody. Na druhou stranu to není zlaté vejce. Na mnoho aplikací bude tento způsob vývoje zbytečný overkill.

Pokud ta domain vrstva pracuje s nějakými datovými entitami, není důvod, aby byly definovány dvakrát. Většina ORM knihoven umožňuje provádět operace "nasucho", bez databáze.

24. 1. 2020, 15:21 editováno autorem komentáře

Ne nutně je třeba mezi vrstvami budovat vlastní abstrakci. A ne ve všech jazycích přináší abstrakce nutný balast kód navíc (např. se podívejte jak realizuje "rozhraní" Dart).

Rozdělení na vrstvy má rozdíl například i (a skoro bych řekl hlavně) v tom, jakým směrem vám jdou závislosti uvnitř kódu. To vám i třeba později, když je to potřeba, umožní rozdělit monolit na více služeb bez většího refactoringu. Je to případ právě té doménové vrstvy.

Tady není asi úplně prostor to rozepisovat, ale dobře udělaná architektura práci šetří, nepřidělává. Zlepšuje orientaci v projektu, nezvyšuje složitost. Pokud se tak někde děje, je ta architektura navržená nebo naimplementovaná blbě.

K vašá otázce na "proč zrovna tolik vrstev": Onion architecture vychází ze zkušeností z mnoha projektů. Stejně jako spousta jiných architektur. Prací každého inženýra/architekta je zvážit možná řešení pro daný problém a zvolit to v danou chvíli nejlepší. Silver bullet neexistuje.

Ono na papíře to vypadá krásně a je dobré, že se začátečník dozví, že má dělat interfacy, ale realita je bohužel poněkud složitější.

To co dělá výměnu komponenty složitou je změna kontraktu a to jak moc se aplikace na danou komponentu odkazuje. Samotný interface moc nepomůže, když je kvůli výměně třeba změnit způsob volání funkcí (parametry, pořadí, ...) a je to rozlezlé na tisíci místech. Naopak pokud mám odkazy na danou komponentu lokalizované v nějaké malé části, tak ji (pravděpodobněji) snadno vyměním i když tam ten interface nebude.

Jinými slovy, žádná architektura nepomůže, pokud se ty špagety stejně rozlezou v aplikační nebo doménové vrstvě, na druhou stranu architektura není zas tak podstatná, pokud jsou věci oddělené a uklizené.

Píšu to proto, že jsem v posledních letech svědkem toho, jak se dogmaticky a extrémně aplikují SOLID principy a všelijaké architektury s devastujícími dopady na aplikaci samotnou. Takže prosím všeho s mírou, dobré integrační testy a uklízet po sobě, to se mi osvědčilo nejlíp :-)

Tak trochu pokritizujem a prihrejem svoju polievocku. Vrstvy v architekture mam roky. Potom sa zistovalo ktore a ako ich rozdelit. A tak vznikli nejake best practices a pre DB orientovane aplikacie ktorych je 99% sme prijali za standard DDD (Domain Driven Design). No potom prisli programatori a zacali to kazit, kod si pisali kde ako chceli a ked ste ich tvrdo nekontrolovali a netrestali tak to prznili kde sa dalo. Tak sme prisli s MDA (Model Driver Architecture). Takze v nejakom DSLku si navrhnete entity, rozhranie, ... a vela kodu to vygeneruje. Programator potom dostane uz iba svoj maly piesocek ktory neviem preliezt alebo je lahke zistit kedy sa o to pokusa. Ak mate zaujem sa trochu pohrat skuste napriklad toto: http://sculptorgenerator.org/ a Documentation -> Advanced Tutorial. Tam sa dozviete ako jednoducho udrazat model, api pod jednou strechou, architektovi umoznuje velku flexibilitu a silu obmedzit programatorov v przneni kodu a zavedie poriadok do projektu.
Neviem inac preco sa tu teraz o tom pise, toto boli zaujimave temy mozno tak 10-15 rokov dozadu.

Zajímavý projekt. Nevím, zda to dobře chápu, ale co se stane s vygenerovaným kódem při požadavku na změnu (každodenní chléb živého projektu). Programátoři dostanou nově vygenerované "API" třídy a musí stávající kód na ně upravit, aby se jim to zkompilovalo?

Dostane vygenerovane predpripravene metody. Default uz maju nejaku implementaciu v base classe ktory sa vzdy pregeneruje. Plus ma vygenerovany interface.
Pokial do vygenerovaneho classu nezasiahne tak ten sa pri dalsom generovani tiez vygeneruje nanovo. To je dobre v case burliveho uvodneho vyvoja kedy sa hlavne hrabete v model.btdesign.
Potom ked si uz nejaku metodu upravite a zmenite rozhranie tak interface vas prinuti tuto metodu implementovat. Standardne CRUD (findById, findByCondition, save, delete, ...) operacie sa generuju automaticky. Je to enterprise grade vyskusane na vela velkych projektoch. Podporuje to aj dalsie rozsirenie pre CQRS a EventSourcing pripadne mozte vygenerovat rovno aj webovu aplikaciu alebo REST.

Pěkný projekt. Našel sem nedávno v projektu https://github.com/ddd-by-examples/library toto https://www.archunit.org , ale zatím jsem to nezkoušel.

"Šedivá je teorie, zelený strom života." Podle mne by se k článku hodil nějaký reálný příkládek.

Technologická nezávislost na databázi je obtížně dosažitelná. Např. SAP a podobné firmy to řeší specializovanými "plugins", které překrývají rozdíly mezi jednotlivými databázemi. Vyčerpávajícím způsobem se k tomu vyjadřuje Tom Kyte již ve starší knize: https://www.knihydobrovsky.cz/autori/thomas-kyte-169801, kterou ale lze nadále doporučit - její větší část je nadále aktuální. Resp. tentýž autor v jiné knize (Oracle Expert Architecture) píše o úskalích převodu aplikace napsané pro MSSQL na Oracle DB a naopak. Nezávislost na databázi je iluze - v praxi se opakovaně setkávám se špatně fungujícími aplikacemi v důsledku ignorování vlastností kontkrétního RDBMS. Resp. v "malých rozměrech" na dnešním HW funguje lecos, ale realita se ukáže na aplikaci datově náročnější a s větším množstvím "concurent users".

Souhlasím že nezávislost na DB je iluze, pokud už s tou DB musím pracovat. Ale DDD právě odděluje doménovou vrstvu od té perzistetntní. Takže když se hrabu v modelu, nic takového neřeším -- repositories jsou definované jen pomocí rozhraní. Pokud se hrabu v infrastruktuře, tak už při implementaci řeším jestli to repository pracuje s MySQL, Postgresem nebo jiným typem úložiště.
Pokud jsou ale systém prorostlý ukládáním do DB už na úrovni modelu, tak to asi je docela problém.

Dobrý den,
podle příspěvků se zde sešla řada zkušených programátorů. Já toho využiju a zeptám se takto do pléna na radu.
Jsem odborností strojař a v rámci svého působení se učím programovat v Pythonu. Pokud rozlišujete kodery a programátory, pak jsem zatím koderem. Používám OOP a učím se postupně data structures a design patterns. Dosud jsem psal převážně jednoúčelové skripty, kdy jsem nic moc nepotřeboval. Našel jsem si příslušnou knihovnu, udělal pár tříd a bylo hotovo. Můj "interface" s kolegy je převážně nějaký textový soubor s daty a výsledky.
Začínám ale pracovat na větší aplikaci a rád bych se naučil, jak to dělat dobře. Tedy jaké jsou best practises v oblasti architektury. Hledal jsem na to nějakou knihu, která by mě uvedla do tématu, ale našel jsem pouze tuto: amzn.to/2tbgE3s a nejsem si jistý, jestli je to, co hledám.
Rád bych se proto obrátil na Vás - zkušené programátory, zda byste mě mohli odkázat správným směrem. Hledám tedy něco, od čeho bych se mohl odpíchnout při programování své první větší aplikace. Nerad používám čistě přístup pokus-omyl. Raději si o problematice nejdříve něco nastuduju, abych věděl, co vlastně dělám. Zároveň aplikaci nechci jenom nějak zbastlit, ale rád bych u toho pochopil všechny důležité principy a jako výsledek dostal kvalitní aplikaci, se kterou půjde dál pracovat. Vůbec mi nevyhovují online kurzy, nejlépe se mi učí z knih, či online textů (které si můžu vytisknout).
Pokud tedy víte o knihách, článcích, skriptech nebo přednáškách, které by mi v tomto smyslu pomohly, budu velice rád, když se o ně podělíte.

Často tady u článků čtu "nářky" nad (ne)kvalitou začínajích programátorů. Rád bych se z této množiny posunul někam dále. Berte to tedy i tak, že teď máte možnost někoho popostrčit správným směrem.
Kdyby byl někdo ochotný k příležitostnému mentoringu/code review, byl bych velmi vděčný.

Snad to není příspěvěk zcela mimo, případně se omlouvám.
PS: a.jelinek zavinac pm.me

Obavam sa ze ak sa chystate robit vacsiu aplikaciu v Pythone caka vas prepis.

To jsi mu fakt poradil.

??? Jak to mám chápat?

Několik základních rad (vycházím ze zkušenosti):

1. Než začneš psát, zkus si základní věci rozvrhnout na papíře
2. Nenech se svést ke zneužívání jednoduchých datových struktur. Žádný dict dictů dictů v situacích, kde je struktura dat pevně daná a známá - hezky to zabal do tříd s konstruktory apod.
3. Používej srozumitelné identifikátory tříd, proměnných apod. Ušetřené písmenko fakt v těchto situacích nestojí za to.
4. Jednotlivé stavební bloky dělej co nejsamostatnější, nemíchej jednotlivé vrstvy mezi sebou a to ani v komentářích - nepiš do funkcí a metod, kdo je používá a proč.
5. Nesnaž se vynalézat kolo; pokud existuje stabilní použitelná knihovna, používej ji.
6. Nauč se dobře pracovat s nástroji typu pylint a vyjdi jim vstříc - pokud danému kódu pylint nerozumí a píše chyby, zkus to napsat jinak.
7. Nepiš nic, co nepotřebuješ. Soustřeď se na funkčnost, která je pro aplikaci nezbytná.
8. Zkus si časem nastudovat jiná paradigmata, zejména funkcionální programování. Otevře Ti to oči.
9. Nauč se porozumět složitosti algoritmů, ať se nezabýváš mikrooptimali­zacemi, které nic podstatného nespraví.
10. Pořád se snaž zlepšovat svoje postupy a nástroje. Co můžeš, zautomatizuj.

Příručka Ti možná pomůže, ale je potřeba si udělat pořádek v hlavě a přemýšlet nad vším samostatně a kriticky. Zároveň nezůstávat v zóně komfortu.

26. 1. 2020, 12:43 editováno autorem komentáře

k bodu 3.
Moc to neprehanej protoze nazvy KeyManagerSer­visniUnitTestMo­dul a KeyManagerSer­visniUnitRunMo­dul se fakt tezko rozlisuju.

Dlouhy nemusi znamenat srozumitelny a naopak. Tohle je doufam jasne.

Za mě doporučím určitě se podívat na prvních 6 částí Clean Coders. Je to o tom jak strukturovat kód a pak unit testy. https://cleancoders.com/videos?series=clean-code&subseries=fundamentals .

Jak už bylo zmiňováno SOLID principy, tedy kniha Clean Code.
Problém je v tom, že člověk přečte knihu a nespojí si všechny věci dohrami a až na základě zkušeností si začne uvědomovat, co kdy platí za jakých podmínek. Kdy co dodržovat a kdy je to hovadina.
Nevýhodou je, SOLID a Clean Code je částečně i dost záplata na to jak špatné je OOP a jakou komplexnost a problémy generuje. Navíc mi příjde, že Clean Code dost prosazuje OOP a nedává do kontextu s Funkcionálním programováním. Navíc je v mnoha věcech dost fanatický.
Problém SW Engineeringu je právě v tom, že se v čase dost vyvíjel a prosazovali se často věci od kterých se postupně upustilo. Takže dosud nevím o nějakém materiálu o kterém by se dalo říct: ''Tohle přečteš a seš dobrý programátor". Skutečnost je spíš taková, že člověk se musí prohrabat spoustu nesmyslama, aby přišel k něčemu dobrému. (IMHO jako tento článek)

Další věc je, že se často nevyplatí o věcech dlouho teoretizovat a jít do toho. Jak se říká "Nejlepší analýza je implementace". Tedy je lepší něco zkusit, ale mít poté možnost to dobře refaktorovat a měnit, když je to nesmysl. A na to, aby se to dalo dobře měnit potřebuješ něco z 6 částí Clean Coders. A přece jen jsme lidi a produktivita se odvíjí hodně od toho jak to člověka bavý. Zmého pohledu je zábavnější psát kód něž neco dokola analyzovat (něco čeho se také týká sOlid - Open-Closed principle).

Dostal jste tu spoustu dobrých rad, tak jen doplním ještě navíc:
* napoprvé se to nepovede, zbastlíte to a za 5 let si budete rvát vlasy, co jste to spáchal. Je to normální. Nenechte se tím odradit. Načíst se dá jen omezená množina věcí, zbytek je o zkušenosti. Zkušenost se dá nabýt od zkušených kolegů a dobrých vyučujících na VŠ. Pokud ani jedno nemáte, nezbývá Vám, než si tu zkušenost udělat sám.
* rozvrhněte systém od shora (velké logické celky, procesy, komponenty - věci které z podstaty věci patří k sobě) dolů (konkrétní moduly/třídy/fun­kce). Nedjřív myslete z pohledu uživatele, zákazníka. A až když jste si jistý, že víte co se po vás chce se zamyslete nad tím, jak by se to dalo naprogramovat.
* nebuďte líný psát automatické testy, je to opruz skoro pro každého, ale alternativa bez nich je strašná
* kdykoliv budete mít potřebu vzít kus kódu a rozkopírovat ho na víc míst, zastavte se, zamyslete a zjistěte kde vám chybí třída/metoda/funkce :)
* komentujte i zřejmé věci, API, atributy, ne zcela triviální algoritmy
* přehlednost a standardizace jsou důležitější než cool-factor, pokud je projekt větší než triviální a životnost delší než krátká (pokud tedy neděláte něco tak nového, že na to standardní řešení nestačí, ale to je jiná story). Používejte ozkoušené knihovny, technologie, principy
* pokud přejímáte řešení problému ze stack overflow či blogu, buďte si nejdřív jistý, že chápete co přesně to do detailu dělá, jinak si koledujete o problémy (výkonostní, bezpečnostní).

Přidám ještě pár připomínek k předchozím. Přijde mi z toho dotazu, že očekáváš, že po nastudování dostatečného množství knih a pouček sedneš a napíšeš dobrou aplikaci. Obávám se, že tak to nefunguje. Jednak principy se časem (trochu) mění, druhak během implementace ani nepoznáš, že jsi něco nedodržel nebo zbastlil. To se ukáže až časem, kdy to budeš potřebovat rozšířit a implementovat nové požadavky atd.

Naštěstí SW umožňuje aplikaci libovolně předělávat a považuju za jednu z klíčových dovedností toto využít. Vychází to z agilních praktik, extrémního programování a konkrétně jde o to, aby se programátor nebál nedělat nic navíc (i když ví, že to řešení časem nebude stačit) a následně to vylepšil když to stačit přestane.

Kolikrát vidim, že se na začátku projektu rozhodne technologie, architektura atd. Následně se to implementuje, přičemž se řeší hromada složitostí, aby to bylo připraveno na budoucnost (která ale bude stejně jiná než kdo čekal) a přitom se nemění architektura ačkoli už dávno nevyhovuje současnosti.

Není nic špatného když si něco nastuduješ, ale zároveň se neboj pustit do prototypů a průběžných předělávek když jsou potřeba.