Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?
Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.
Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.
u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)
Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.
Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.
V žádném případě nejsem příznivcem monolitů a proto se mi nelíbí, jak se toho zhostil autor zmíněného blogu. V každé třídě hezky 2-4 atributy a 3-7 metod. Víc není třeba. Skupinu tříd, která se stará o jednu doménu, dám do jednoho adresáře. Domény, které jsou logicky nad ní nebo pod ní, jsou v jiném adresáři na stejné úrovni. Můžeš to srovnat s hexagonální architekturou, která nevytváří zbytečnou hierarchii.
Specializaci tedy nedělám podle kategorie, ale podle domény. Pokladna, sklad, ceník, košík. V každé doméně je kompletní MVC, třídy hezky vedle sebe. Když vytvářím další doménu, například slevy, tak nemusím běhat po celém vývojářském stromu, ale mám celé MVC pohromadě v jednom adresáři. Pokud by mi měla vzniknout duplicita kódu s jinou doménou, tak tu část kódu refaktoruji do nové domény a ta si pak žije svým životem.
Adresář s názvem "domain" u mne postrádá smysl, neboť bych v něm měl všechno.
Zobrazit příspěvky
. Ked uz chcete ist od Javy tak naco patlat v JS, skus radsej Python. Myslim ze vo verzii 3 dozrel "skoro" k dokonalosti. Nerozumiem naco patlat v JS ked mame Python a dnes obrovsku infrastrukturu okolo.