A pokud bych chtel pouzit treba OOA&D, tak mi jeste unika jak prevest koncept systemu na konkretni komponenty. Kdyz ma system byt treba custom workflow engine, tak jake high-level komponenty se obvykle nachazeji ve workflow engine? Nebo kdyz to ma byt treba recruitment system, tak jake high-level komponenty se obvykle nachazeji v recruitment systemu? A nebo kdyz to ma byt CRM, tak jake high-level komponenty se obvykle nachazeji v CRM?
Obvykle komponenty je potreba znat, protoze ony tvori pevne a nemenne jadro, neboli tvori hlavni koncept systemu. Napr. bez konkretni komponenty by to uz nebyl workflow engine, nebo by to uz nebyl recruitment system, nebo by to uz nebyl CRM.
Tohle by me opravdu zajimalo. Pres OOA&D si muzeme navrhnout nove komponenty, ale nevime jake komponenty tam museji byt pro tento druh systemu (napr. pro workflow engine). Leda ze by se nasel standard, tzn. jeden diagram, ktery by ty fixni a nemenne komponenty mel zakresleny, a bylo by hned jasne co workflow engine presne ma uvnitr. Totez by pak bylo jasne i pro recruitment platformu, i pro treba CRM.
A kdyz takovy standard se nenajde, tak kazdy system tam ma jine komponenty, pojmenovany jinak, rozdeleny jinak, mozna i s jinym jadrem, a neni jasne jak rozlousknout co to jadro vlastne je. Leda ze by se obeslo treba 10 prednich workflow enginu a z nich se nejakym otresne neefektivnim zpusobem vydestilovalo co maji spolecneho (komonalita) a v cem se lisi (variabilita). Ale jak to z nich alespon vytahnout efektivne?
Tento problem nastava u kazdeho systemu, dosud ne zcela znameho tomu, kdo na nem ma pracovat. A je to nejcastejsi pricina komplikaci (spatneho designu, spinaveho kodu, i neefektivity). Kdyz tam ten diagram bude, tak bude mit kazdy jasno v komponentach, jejich vyznamu, i jejich usporadani, a v kodu bude cisteji, a bude to strukturovanejsi.
Muze nekdo poradit co se v praxi pouziva, aby to bylo vyreseno rychle a snadno, a nemuselo se psat jeden system a pak ho X krat prepisovat do jinych komponent, protoze poprve byly spatne?