Аз тука с корона и 38 температура да се обадя - питонаджии спориха с мен, че било безсмислено да се ползват интерфейси :)
Еми заради 38-те градуса да го кажа някак си по-меко - това дето ти и аз разбираме под архитекстване в часта с коденето се различава доста, затова не е смислено да спорим
Ами не знам какво разбираш под архитекстване, дай примери. На Юджийн лесно му влизам у сурата, представям си, че съм на 15 и е лесно, при тебе е по-трудно.
Еми дай да видим колко сме различни, да кажем ще се прави продукт за интернационална фирма, т.е. с поделения в различни страни, с бизнес да кажем в областта на търговията, ще се наследяват данни от няколко предишни системи. Ти ще си архитектчи само на бекенда, като ще правите кооперация с още една фирма и ще има 2 екипа - един от твоята, един от другата фирма. Решили сте да ползвате микросървиси или нещо подобно, т.е. двата екипа ще правите два отделни модула или както щеш ги наричай, които ще си говорят през някакъв интерфейс, да кажем жсони. Имаш цялата власт да кажеш какво и как да се пише, да кажем всички ще са на .net/c#, много е вероятно двата модула да черпят различни данни от различни системи в различни страни. Екипите си имат достатъчно опитни лийдчета, дали са на един акъл за архитектури и прочее - Божа работа. Какво ще проектираш ти, т.е. до каква степен и най-вече от какви съображения?
Ще задам конракт за комуникция между модулите, точно както ти си избрал по-горе, а вече който както иска да си имплементира модулите, в зависимост какви легаси лайна трябва да вкара в себе си. Там кой колко велик лийд е на екип - над тея неща съм, това е за пуяци и младежи. Сега ако има перформънс проблеми и тая комуникация през контракт се бави, може да се наложи месидж шина. Ако и тя е греда, накрая могат да почнат да дрискат всички сървиси в някакво диби, което може да наложи допълнителни споразумения между екипите. Но тук вече гадая, както вие ми отговоряхте на "обширен въпрос, без конкретика" в една друга тема.
Еми ето каква е разликата - за мен първия въпрос ще бъде кой ще поддържа кода от модулите, т.е. дали има шанс единия екип да поддържа кода на другия, тогава освен комуникацията ще проектирам и системата до ниво класове например, т.е. с цената на това да ме мразят, съответно да имам проблеми по време на разработката ще елиминирам голяма част от проблемите при разместване на екипи и прочее.
Като цяло архитектурирането (и въобще софтуерното производство) включва много повече от технологиите, това всеки го признава и почти никой не го прилага, всъщност това е един от показателите за опит, в крайна сметка важи принципа за най-слабото звено, целта на всяко едно решение би трябвало да бъде да е най-оптимално за крайния резултат (оптимално = най-добро за най малко ресурс), съответно колкото по-нагоре е решението толкова по-отговорно е. Архитектурирането като един от високите класове решения трябва да е възможно най-обхватно, за да е и най-оптимално, за да е най-обхватно означава да отчита възможно най-много показатели, в момента в който се вторачиш повече в едните вдигаш шанса TCO-то на проекта да расте.
Като цяло тия разговори не са много забавни именно защото хората имат много различни мнения, силно се отива в плоскостта "плоска ли е Земята или не" (харесват ми тафтологиите), но в крайна сметка нали сме ИТ форум и поне може да си чешем езиците