Literatura – jak implementovat modulární systém?

svezij

Ahojte, neznáte někdo literaturu – knihu, skripta, články, tutoriály atd. – ohledně vývoje modulárního systému? Dělá mi poměrně velký problém se v hlavě vůbec zorientovat a navrhnout takový systém. Neustále vyvstávají nové dotazy, nemám na ně odpovědi a začíná se to zamotávat a zamotávat.

Potřeboval bych zkrátka celou aplikaci rozdělit na jednotlivé „moduly“ (pravděpodobně potomky CompilerExtension), které budou mít vlastní služby, komponenty, případně routy, presentery a já nevím co ještě a budou propojeny s jádrem systému, který s nimi bude pracovat. Moduly budou schopny navzájem komunikovat (asi přes observer) atd.

Tzn. budu-li v budoucnu potřebovat např. v e-shopu přidat platbu pomocí platební brány, prostě udělám modul, nachystám komponenty, případně routy, presentery a šablony pro jejich zprávu. To vše budu vyvíjet, aniž bych jakkoliv zasáhl do funkčního systému, a poté modul během pár hodin propojím s funkční aplikací a „tadá“, mám novou funkčnost v systému.

Díky, mějte se.

Felix

Mam za to, ze zadny obecna literatura jak stavet Nette do modularniho systemu neni, protoze mas takovych specifickych veci, ze to snad ani nejde.

Jsou jen nejake obecne postupy, cemu se vyhnout, jak co udelat. Ale nikde sepsane nejsou bohuzel.

Pokud se chces inspirovat, urcite nejake reseni v Nette je.

Napr.:

svezij

Děkuji, nejde mi o literaturu pro „modulární Nette“, proto jsem dal dotaz do OT, jde mi o ty obecné postupy. Jinak na Venne koukám a podívám se i na flame-org. Každopádně mi přijde velmi nepravděpodobné, že by nikdo nikdy nikam nesepsal nějaké obecné zásady či postupy pro vývoj modulárního systému. Zkusím se do toho opřít a trochu víc pohledat, třeba něco najdu. Každopádně díky a díky i ostatním za případné další příspěvky.

Svaťa Šimara

Ale ano, literatura existuje. Je důležité si uvědomit, že Nette je jen a pouze infrastruktura pod Tvou aplikací, a můžeš dokonce napsat aplikaci tak, že bude tato infrastruktura zaměnitelná.

To, co tady píšeš – oddělené moduly a jejich komunikace mi krásně připomíná Bounded Contexty a jejich integrace z pohledu Domain-driven design od Evanse. Nedávno vydal jeho kolega Vernon užší knížku, kterou jsem ale ještě nečetl: DDDD . Mimo jiné existuje od Vernona Implementing DDD , a ta pěkně doplňuje DDD o implementační detaily, které nejsou vůbec, ale vůbec zřejmé.

edit: Doplněno o další knížku a upřesněno

Editoval Fafin (23. 6. 2016 10:54)

newPOPE

Doporucujem toto https://leanpub.com/ddd-in-php za den/dva precitane a dobre napisane.

Jiří Nápravník

Snažím se o modulární aplikaci, ale není to samozřejmě zatím 100% a ty moduly jsou na sobě závislé. Ale pokdu začínáš, mohu poradit zatím, kam jsem se dostal já a co to chce pořešit.

Určitě každý modul vlastní CompilerExtension, která bude využívat Flame\Modules, který ti řeší rozšiřitelnost na pár řádcích přidáš vše potřebné, od entity, přes filtry, atd. Ve Flame\Modules se můžeš inspirovat i jak pak případně řešit nějaký providery pokud tam nejsou, třeba webloader apod.

Pro databázovou vrstvu bych doporučil doctrine, mají EntityResolvery, kdy v podstatě nepracuješ s entitou jako takovou ale interfacem, či-li si můžeš podstrčit potom entitu obohacenou o nějaké další atributy z jiného modulu. Kdyby\Doctrine má chybu v těch EntityResolverech, zatím to nijak neřeší, pokud budeš chtít psát větší aplikaci, tak mrkni na githubu na fork jirinapravnik\Doctrine, které to opravuje, snad to mergnou časem.

Já zatím nijak moc extra neřeším komunikaci mezi moduly, v podstatě to potřebuji převážně pro věci jako, chci smazat štítek, není někam přiřazen, a je přiřazen třeba k fotkám, článkům apod. Tak na to používám Kdyby\Events, kdy vystřelím event, listener to zachytí a řekne, že tyhle články ten štítek mají ať nic dál nedělá.

svezij

@newPOPE Díky, už pročítám.

@JiříNápravník
I tobě díky, určitě se podívám na flame\modules a uvidím co a jak. Co se týká ORM, tak používáme Nextras\Orm a zdá se nám super. Nevím, jak je to s Doctrine, možná taky kouknu. Btw když už se to nakouslo, největší problém skoro všech ORM jsou prefixy. Co Doctrine? Řeší je nějak elegantně? Konkrétně chci např pro všechny tabulky globální prefix blah_, pro všechny tabulky konkrétního modulu potom blah_ext_modid_, kde to blah_ je globální prefix a ext_ značí, že se jedná o modul a modid_ je pak prefix specifický pro každý modul. Když v systému zavolám něco na tabulku users, tak se tam automaticky doplní prefix blah_ a vnitřně se dotaz bude volat na tabulku blah_users, když něco zavolám na tabulku users uvnitř modulu, pak se automaticky doplní prefix blah_ext_modid_ a vnitřně se volá blah_ext_modid_users ⇒ jsou to odlišné tabulky. Vždycky bych ale měl mít možnost zavolat si zevnitř modulu tabulku systému nebo tabulku modulu jiného (tedy získat nějak prefix požadovaného „místa“). Umí s prefixy takovým nějakým způsobem pracovat Kdyby\Doctrine? Díky

Edit: doplnění informací

A na komunikaci mezi moduly a systémem atd. používáme také Kdyby\Events.

Editoval svezij (23. 6. 2016 14:18)

Felix

Fafin napsal(a):

Ale ano, literatura existuje. Je důležité si uvědomit, že Nette je jen a pouze infrastruktura pod Tvou aplikací, a můžeš dokonce napsat aplikaci tak, že bude tato infrastruktura zaměnitelná.

To, co tady píšeš – oddělené moduly a jejich komunikace mi krásně připomíná Bounded Contexty a jejich integrace z pohledu Domain-driven design od Evanse. Nedávno vydal jeho kolega Vernon užší knížku, kterou jsem ale ještě nečetl: DDDD . Mimo jiné existuje od Vernona Implementing DDD , a ta pěkně doplňuje DDD o implementační detaily, které nejsou vůbec, ale vůbec zřejmé.

edit: Doplněno o další knížku a upřesněno

Ano, pravda na tohle jsem zapomnel. Nahlizel jsem na to spis konkretne jak Nette vetvit do modulu, tak aby se z toho clovek nezblaznil. :-)

Jiří Nápravník

svezij napsal(a):

ja osobne pouzivam jeden prefix pro vsechny tabulky v aplikaci a bez problémů. Nějak lehce poupravený tohle mám . Osobně nevidím problém, proč bys nemohl definovat i různé prefixy pro více tabulek, nějak si je odliším třeba anotacemi, a nastavíš prefix podle toho…

Svaťa Šimara

@svezij
Rozhodně doporučuju používat Doctrine. Už jsem si prošel Nette\Database, LeanMapper, a je to běs (Nextras\Orm hodnotit nemůžu). V Doctrine je toho hodně, opravdu hodně vyřešeného, a další věci se vyvíjí – prostě jistota.
Za killer feature Doctrine považuju nepotřebu dědit entity od ničeho – tím se dotáhne čistých tříd a jednoznačné zodpovědnosti (pokud musím v ORM dědit, má moje entita 2 zodpovědnosti – svoji logiku + persistenční logiku).

Pokud už Doctrine, tak čistou – doctrine/orm. Kdyby/Doctrine obsahuje kotel kódu, který je navíc závislý na dalších balíčcích, celkově jde o zcela postradatelnou vrstvu. Kdyby/Doctrine má navíc oproti původní doctrine trochu jinou filosofii, která se navíc časem mění.

Pokud události, rozhodně doporučuju symfony/event-dispatcher, jde o čisté, nemagické, jednoduché události. Opět – Kdyby/Events bych rozhodně nebral.

Co se týče prefixování – budeš psát nativní SQLka? Pokud ne, a budeš používat DQL, prefixovat není potřeba, protože nikdy nebudeš nikde zmiňovat názvy tabulek. Pokud už bych ale z nějakého důvodu prefixovat potřeboval, řešil bych to ručně v definici mapování – je to jeden řádek navíc, mapování obvykle obsahuje spustu řádků, ten jeden už se ztratí.