Потому что я оцениваю любую архитектуру с точки зрения того, насколько хорошо она решает поставленную задачу.
Ну так она может лучше решать вашу проблему, но быть очень дорогой для проекта. От этого она хуже ее не решает.
Можно. Ничего не мешает.
Ну можно, конечно. Так то взять, то как хочешь пиши. Можно называть переменные в коде (а,b,c). Почему вы так не делаете? Или может и делаете. Может и в этом вы не видите ничего плохого.
Гм. Можно иметь REST и типизированный контракт при этом.
Можно, но зачем. Если можно то, что принял — сразу же и отдать?
А откуда фидбек-сервису это знать? И как гарантировать, что его структура article info такая же, как у сервиса поиска?
Ну можно кинуть референс на артиклы. Будет зависимость. Но артиклы об этом знать не будут.
Нет, вы серьезно не понимаете, что плохого в не типизированных контрактах?
Что конкретно вы имеете в виду под не типизированными контрактами?
И пользы с этого? Нам надо найти, где оно лежит, чтобы его поправить.
Искать проще
И если вы мне хотите сказать, что с ростом проекта число мест, где может лежать строка, не увеличивается, вы меня обманываете (ну или не понимаете, как это работает).
При адекватной архитектуре число мест должно остаться прежним, или же меньшим в сравнении неиспользования архитектуры
С абстрагированием — тем более везде. Я вас как-то просил привести список архитектурно правильных мест, где может быть это сообщение, вы до сих пор этого так и не сделали.
Я сделал это. Архитектура дает понять где что-то быть НЕ МОЖЕТ. А не где оно точно будет, ибо нету стандартов архитектуры, она может видоизменяться под нужды проекта.
Я не понимаю, как вы оцените объективно хорошую архитектуру. Нету их, потому что любая оценка архитектуры неизбежно привязана к задаче, а задача привязана ко мне.
конечно, но есть много похожих архитектур, которые решают похожие задачи. И скорее всего, архитектура не решает одну задачу, а многие. В вашем случае — она может не решать вашу задачу. В другом случае, она может решить чью-то задачу. Так почему же она плохая, только потому что ВАШУ проблему не решает. Другие, для других людей\задач — может решать
Вот я и говорю — нельзя просто взять и вынести сборку за REST.
Ну вот и я говорю, что не можно просто так взять, и запихнуть фидбек в артиклы.
Да, это его ответственность, она же его бизнес-логика, она же — одна из причин его изменения. Одна, но не единственная
как по мне, то единственная.
Вы это серьезно? Вы серьезно не понимаете, что плохого в нетипизированных контрактах?
ну рест, не типизировнный контракт, и что? Его используют тысячи апликейшнов.
… например, пытается ее десериализовать в FeedbackMessage, и падает. Это вроде бы не то, что нам надо в системе.
зачем? десериализовать надо в Артикл инфо.
(srsly?)
да
Во-первых, потому что раньше был код, который делал HTTP-запрос, а теперь он пишет в очередь; аналогично на другой стороне раньше был код, который HTTP принимал, а теперь он из очереди читает.
А во-вторых, у вас был синхронный протокол, а стал асинхронный.
Удивительно, но в системе, которая разработана не по правилам выше, будет так же — спросить где хранится, и там найти. Получается, что в данном примере выигрыша нет.
так вы раз спросите, потом будете знать где искать ту или иную логику. Без абстрагирования, эта логика может быть везде, проще искать в каком-то участке(модуль, папка..) или во ВСЕМ проекте?
Там был момент, если проект ведешь один, то абстракция не упрощает. Так вот упрощает, потому что по прошедствии времени, часто забываешь, что и для чего ты делал там, или иначе. Вспомнить будет намного легче, если проект разбит на отдельно, логически-изолированные модули.
Повторяю еще раз: архитектура, которую я не могу использовать, для меня плохая. Потому что ни зачем не нужна.
Повторяю ещё раз: ну так для вас, в КОНКРЕТНОМ случае плохая. Это не делает её объективно или абсолютно плохой, а только субъективно, в вашем случае.
… а потом выясняешь, что один из параметров запроса — Func, и смотришь, как прекрасно он сериализуется. Или, что проще, видишь, что метод вызывался настолько часто, что из-за дополнительных расходов на HTTP система замедлилась вдвое.Это зависит от нужд проекта.
А то, по каким конкретно полям, и с каким весами? А дополнительные фильтры? Ну и самое главное — реранкинг, сейчас — общий, а в будущем — с учетом пользователя?
Так это и есть его ответственность. Но точно не имплементить фидбеки в себе.
У вас все сервисы между собой общаются по нетипизированным контрактам?
А что в этом плохого? Будет моделька конкретная АртиклИнфо какое-нить, её сериализуешь, а далее фидбек делает что хочет.
на шину сообщений код придется править в двух местах
Почему, так же сериализнул и кинул на какой-нить ребит. Не вижу проблемы.
Тут есть маленький нюанс: это хорошо работает, пока человек один (и его восприятие не меняется). Когда людей больше одного, может внезапно выясниться, что выделение более и менее существенных элементов у них разное.
Ну для этого и есть тима, которая должна коммуницировать. И если проект очень большой — и развертывают все в микросервсах, что бы каждая тима, могла максимально независимо работать над своим микросервисом. Так же пишется документация, по конкретным конвеншнам архитектуры и проекта в целом.
Так зачем мне архитектура, которая не подходит к моей задаче?
так не используйте, но от того, что вы её не используете, она хуже не станет.
Неа, нельзя.
Можно: перемещаешь имплементацию с абстракцией в новый рест сервис, и накатываешь для этого ХТТП запросы. Вуаля. Но только перетащить два файла — это не копаться во всех артиклах, в поисках отпраки фидбека.
Изменились бизнес-требования
при чем бизнес требования к серч енджайну — он выполняет поиск по текст в статьях и все.
Фидбек-то отдельный сервис, но мне в него надо писать в конкретное время и по конкретным условиям, а они — часть сервиса поиска.
ток киньте это в джсон и отпраьте на рест(в фидбек). Фидбек сервису будет все равно, что ему отправят — он получил и на екстернал сервис какой-то отправил. Все.
Вот-вот. Сначало было «стринга такая-то», а потом решили добавить кокнретного пользователя, который это сделал. В скольких местах придется поменять?
для этого джсон енкодинг придумали. Все равно стринга.
Очень простым: вы хотите добавить в контракт фидбека новое поле, см. выше. В скольких местах придется поменять?
ДЖСОООН. Любую модельку сконвертили, и отправили как стрингу.
… так вот, «должно быть можно разработать нашими силами за месяц» — такая же задача. Если архитектура ее не решает, то это плохая архитектура, негодная.
негодная в одном случае — годная в другом. Это зависит от многих факторов, но сама по себе, она может быть хорошая, хоть и не рентабельна в некоторых случаях.
Это никак не повлияет на количество причин для изменения компонента в целом.
Нет, повлияет. Либа — отдельный, изолированный компонент. Ее с легкостью потом можно поставить в РЕСТ. И тогда — это повлияет. Только вот легче это сделать имея абстракцию, а не лазить по всем артиклам в поисках отправки фидбека.
Во-первых, это уже две причины, и они происходят в разное время.
Нет, это причина измения полнотектового поиска, она одна.
вы забыли изменение клиентского контракта, изменение требований на фидбек
В случае, если фидбек отдельный сервис, тогда опять таки нет. Фидбек: просто набор меседжа, стринга какая-то и все. Если от фидбека нужно будет изменение, например писать ещё все фидбеки в базу, то это не повлияет на артиклы.
Я вам больше того скажу, разделение сервисов статей и фидбека — это нарушение первой части CCP
Ну и каким образом. Я хочу добавить логику, кроме отправки фидбека наружу, писать все из в бд. Зачем мне нужно изменять что-то в артиклах по этому поводу? То есть изменения на фидбек, которое не трогает артиклы. Мне кажется это не «classes that change for the same reasons and at the same times»
Если это делать после разработки — то да, немного. Но тогда все время разработки я буду зависеть от имплементации.
начальное.
Я не понимаю, что вы спрашиваете.
Почему вы говорите об имплементации абстракции, как что-то от третьей стороны, а от просто имплементации, как о чем то своем? В случае абстракции, вы сами же сможете заменить реализацию, так же, как вы собирались менять имплементацию.
Это вы так говорите. А в реальности это далеко не всегда так, и это всегда приносит с собой дополнительные проблемы.
ну мне это не принесло дополнительных проблем, а только облегчало жизнь, на протяжении 1,5 года ентерпрайз разработки. Согласен — может я когда-то наткнусь на эти проблемы, о которых вы знаете, в силу большего опыта. Но пока что, даже если это дает какие-то дополнительные сложности — профит перебивает все равно.
Вы просили пример ситуации, когда понадобилось залезть в детали реализации, и потом за это поплатиться? Вы их получили.
Вы привели пример БИТОЙ реализации. Приведите не битой, которая работает как-надо, а где проблему составила именно абстракция.
Вы так этим восхищаетесь, как будто это что-то важное. Так вот — нет, не важное. А на билд-сервере все равно будет собираться все целиком.
в случае разноса нагрузки — это очень поможет, потому что такие леера легче потом разбить на независимо деплоябельные компоненты.
Тем, что архитектура — это не дом.
Аналогия — это, вроде как, объяснение одних явление через другие, через схожесть по качествам и характеристикам явлений. То, что вы сказали сводить любую аналогию на 0.
… и в этот момент снова не понятно, то ли надо имплементацию менять, а то ли интерфейс трогать
.Интерфейс -стабильнее, поэтому чаще всего — имплементацию.
Поддерживать расширяемость — задача. Поддерживать тестируемость — задача. Позволять работать в облаке — задача. Ну и так далее...
ааа, я вас неправильно понял. С этим полностью солидарен. Кстати говоря, тестировать то проще с абстракциями и интерфейсами. Расширять — тоже проще с абстракциями.
Вы не понимаете. Он отправляет фидбек о том, какие запросы были сделаны. Он должен это делать
Ну в моем случае будет отдельный сервис(по сути класс с интерфейсом), который будет иметь метод — отправить фидбек. Можно сделать отдельную либу, которая будет отправлять что-то наружу. И заюзать ее. Сервис будет делать тоже — возвращать артиклы, только ещё к тому, на каком-то интерфейсе вызывать _externalInteractor.SendMessage(string message). он не будет имплементить это, он просто вызовет метод. Если нужно будет, потом леер, который отвечает за отправку меседжа можно изменять, дополнять — что угодно. Только это будет проще, нежели искать эту имплементацию в методе, где с статьями работают.
«Все правильно» — это сколько у него причин для изменения?
причина — изменение логики, либо чего-то связанного с серч енджайном. Сервис по себе не зависит от посыла фидбек, ибо он это не имплементит.
Неа. Если имплементация используется «по месту», она не является долгосрочным контрактом, поэтому нет необходимости ее проектировать как публичную.
Я не за это. Ваша имплементация будет содержать ендпоинты, которые будут выполнять какую-то логику — так вот теже ендпоинты на интерфейс переложить, вот что я имел в виду — это не много времени. Так как в начале разработки, скорее всего, вы часто будете менять ендопоинты, но позже, когда разработка подойдет к финишу, будет просто стабильный интерфейс(стабильнее, чем имплементация)
Вот только я, например, смогу выбирать, какая реализация мне нужна.
ну если вы разработчик — можете, только вот если вы разработчик абстракции с имплементацией — то что мешает поменять имплементацию так же, как и в случае чистой имплементации?
Неа.
Да, ибо абстракция — упрощает, изолирует логики между собой, это упрощает задачу в изменении. Для чего же по вашему придумали паттерны, к примеру? Потому что были проблемы, вот с такими «грубыми» имплементациями. Все паттерны строятся через абстракцию.
То проблема в имплементации.
Ну вот, но вы же не скажете, что сам алгоритм плох при этом? Или скажете? Именно это вы и сказали, говоря про то, как вы парсили через IIS. То, что майкрософты не углядели баг — не делает саму абстракцию плохой.
Я смотрю, вы любите некорректные аналогии.
А чем плоха та аналогия?
Если имплементация сырая, то потребитель абстракции все равно будет поаффекчен.
Каким образом? Сразу пример. Имею либу(что бы сразу отпали вопросы, либа — потому, что логика будет использоваться повторно), и аспнет. В аспнете интерфейс, имплементация в либе. Есть один метод в интерфейсе, описанный. Билджу все — все окей. теперь, к примеру, нужно кусочек логики переписать в либе. Переписываю — билджу, аспнет не билдится. Почему? потому, что зависимости нету на либу. Либа зависит от абстракции. Все по Депенденси рулу. В случае вырой имплементации, аспнет бы тоже ребилдился.
А на этапе продакшна уже и трогать не надо. Пусть работает.
Не совсем так можно «не трогать», могут реквайрменты поменяться, данные имеют свойство расти и т.д.
Потому что она призвана выполнять задачу. Без задачи это просто чьи-то размышления о благом.
выполнять задачу — это о поведении апликейшна, а архитектура — это о другом, о чем, спросите? — я это выше говорил.
Во-первых, нет, не только артиклы — еще отправка фидбека по запросам.
я говорю оо артиклах без фидбека. Если фидбек включать, я уже говорил, что это был бы отдельный рест скорее всего.
Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons
Все правильно, сервис артиклов — отправляет запрос на серч енджайн — выдает респонс. Если отправлять фидбек — то через абстракцию, — это не ответственность артиклов, потому что они бы не имели имплементации фидбеков.
Вы за пять секунд проектируете интерфейс? Восхищаюсь вами. Я над одним названием метода дольше думаю.
Я за написание, проектировать вы столько же будете и имплементацию(прототипы)
Потому что IoC и DI. Я, как потребитель сервиса, не определяю, какую реализацию сервиса мне передают, я должен работать с той, которую передали
Но и без абстракции, вы будете потребителем, и будете работать с теми методами, которые вам представляют.
Вы забываете про маленький нюанс: не все «сервисы регистрируете» вы. Что вам передали — с тем и работайте, инфраструктура вам не подконтрольна.
та же проблема с имплементациями, они в этом ничем не лучше, а вот для людей, которые «передают», это упрощает жизнь.
Баг не в абстракции, а в реализации. Я не понимаю, зачем просить пример, если любой пример можно отвергнуть с теми же аргументами.
То есть, если вы некорректно напишите mergesort — то проблема в алгоритме, а не в вас?
Нет, не может. Это одни и те же изменения.
Да, изменения те же, только чтобы поменять имя переменной в имплементации к примеру — вам не нужно будет ребилдить, и каким-то образом афектить «потребителя» абстракции — а при имплементации — придется.
Зато не надо тратить ресурсы на абстракцию, это уже хорошо.
но фиксить и менять имплементацию сырую — тоже может быть дороже, кроме того, ты не там много потратишь на абстракцию. В случае Артиклов 5 сек на создание интерфейса, 20 — на написание деклараций.
Вот только я не могу «подставить другую имплементацию под интерфейс», потому что я потребитель, мне все имплементации передают.
не могу понять почему. Простой пример, в DI в аспнете, когда сервис регистрируешщь, меняешь одну иплементацию на другую, при этом все сервисы, которые юзали ту имплементацию. не нуждаются в рефакторинге, фиксинге и т.д. Даже при билде, они билдится не будут.
Баг в абстракции — не проблема абстракции, а проблема разработчиков — это не делает её — плохой. Я просто не до конца понял. что за фейковые страницы, что там и как надо было парсить.
Ну можно, конечно. Так то взять, то как хочешь пиши. Можно называть переменные в коде (а,b,c). Почему вы так не делаете? Или может и делаете. Может и в этом вы не видите ничего плохого.
Можно, но зачем. Если можно то, что принял — сразу же и отдать?
Ну можно кинуть референс на артиклы. Будет зависимость. Но артиклы об этом знать не будут.
Что конкретно вы имеете в виду под не типизированными контрактами?
При адекватной архитектуре число мест должно остаться прежним, или же меньшим в сравнении неиспользования архитектуры
Ну это пока проект не растет, и не усложняется
Ну вот и я говорю, что не можно просто так взять, и запихнуть фидбек в артиклы.
как по мне, то единственная.
ну рест, не типизировнный контракт, и что? Его используют тысячи апликейшнов.
зачем? десериализовать надо в Артикл инфо.
да
И?
Можно: перемещаешь имплементацию с абстракцией в новый рест сервис, и накатываешь для этого ХТТП запросы. Вуаля. Но только перетащить два файла — это не копаться во всех артиклах, в поисках отпраки фидбека.
при чем бизнес требования к серч енджайну — он выполняет поиск по текст в статьях и все.
ток киньте это в джсон и отпраьте на рест(в фидбек). Фидбек сервису будет все равно, что ему отправят — он получил и на екстернал сервис какой-то отправил. Все.
для этого джсон енкодинг придумали. Все равно стринга.
ДЖСОООН. Любую модельку сконвертили, и отправили как стрингу.
Нет, повлияет. Либа — отдельный, изолированный компонент. Ее с легкостью потом можно поставить в РЕСТ. И тогда — это повлияет. Только вот легче это сделать имея абстракцию, а не лазить по всем артиклам в поисках отправки фидбека.
Нет, это причина измения полнотектового поиска, она одна.
В случае, если фидбек отдельный сервис, тогда опять таки нет. Фидбек: просто набор меседжа, стринга какая-то и все. Если от фидбека нужно будет изменение, например писать ещё все фидбеки в базу, то это не повлияет на артиклы.
Ну и каким образом. Я хочу добавить логику, кроме отправки фидбека наружу, писать все из в бд. Зачем мне нужно изменять что-то в артиклах по этому поводу? То есть изменения на фидбек, которое не трогает артиклы. Мне кажется это не «classes that change for the same reasons and at the same times»
Почему вы говорите об имплементации абстракции, как что-то от третьей стороны, а от просто имплементации, как о чем то своем? В случае абстракции, вы сами же сможете заменить реализацию, так же, как вы собирались менять имплементацию.
ну мне это не принесло дополнительных проблем, а только облегчало жизнь, на протяжении 1,5 года ентерпрайз разработки. Согласен — может я когда-то наткнусь на эти проблемы, о которых вы знаете, в силу большего опыта. Но пока что, даже если это дает какие-то дополнительные сложности — профит перебивает все равно.
Вы привели пример БИТОЙ реализации. Приведите не битой, которая работает как-надо, а где проблему составила именно абстракция.
в случае разноса нагрузки — это очень поможет, потому что такие леера легче потом разбить на независимо деплоябельные компоненты.
Аналогия — это, вроде как, объяснение одних явление через другие, через схожесть по качествам и характеристикам явлений. То, что вы сказали сводить любую аналогию на 0.
ааа, я вас неправильно понял. С этим полностью солидарен. Кстати говоря, тестировать то проще с абстракциями и интерфейсами. Расширять — тоже проще с абстракциями.
Ну в моем случае будет отдельный сервис(по сути класс с интерфейсом), который будет иметь метод — отправить фидбек. Можно сделать отдельную либу, которая будет отправлять что-то наружу. И заюзать ее. Сервис будет делать тоже — возвращать артиклы, только ещё к тому, на каком-то интерфейсе вызывать _externalInteractor.SendMessage(string message). он не будет имплементить это, он просто вызовет метод. Если нужно будет, потом леер, который отвечает за отправку меседжа можно изменять, дополнять — что угодно. Только это будет проще, нежели искать эту имплементацию в методе, где с статьями работают.
причина — изменение логики, либо чего-то связанного с серч енджайном. Сервис по себе не зависит от посыла фидбек, ибо он это не имплементит.
ну если вы разработчик — можете, только вот если вы разработчик абстракции с имплементацией — то что мешает поменять имплементацию так же, как и в случае чистой имплементации?
Да, ибо абстракция — упрощает, изолирует логики между собой, это упрощает задачу в изменении. Для чего же по вашему придумали паттерны, к примеру? Потому что были проблемы, вот с такими «грубыми» имплементациями. Все паттерны строятся через абстракцию.
Ну вот, но вы же не скажете, что сам алгоритм плох при этом? Или скажете? Именно это вы и сказали, говоря про то, как вы парсили через IIS. То, что майкрософты не углядели баг — не делает саму абстракцию плохой.
А чем плоха та аналогия?
Каким образом? Сразу пример. Имею либу(что бы сразу отпали вопросы, либа — потому, что логика будет использоваться повторно), и аспнет. В аспнете интерфейс, имплементация в либе. Есть один метод в интерфейсе, описанный. Билджу все — все окей. теперь, к примеру, нужно кусочек логики переписать в либе. Переписываю — билджу, аспнет не билдится. Почему? потому, что зависимости нету на либу. Либа зависит от абстракции. Все по Депенденси рулу. В случае вырой имплементации, аспнет бы тоже ребилдился.
выполнять задачу — это о поведении апликейшна, а архитектура — это о другом, о чем, спросите? — я это выше говорил.
я говорю оо артиклах без фидбека. Если фидбек включать, я уже говорил, что это был бы отдельный рест скорее всего.
Все правильно, сервис артиклов — отправляет запрос на серч енджайн — выдает респонс. Если отправлять фидбек — то через абстракцию, — это не ответственность артиклов, потому что они бы не имели имплементации фидбеков.
почему же?
Нет, потому, что в вашем случае логика будет на посыл фидбека. А в моем, только артиклы.
ну вы когда пишете слой — пишете связанную логично там логику.
Но и без абстракции, вы будете потребителем, и будете работать с теми методами, которые вам представляют.
та же проблема с имплементациями, они в этом ничем не лучше, а вот для людей, которые «передают», это упрощает жизнь.
То есть, если вы некорректно напишите mergesort — то проблема в алгоритме, а не в вас?
Да, изменения те же, только чтобы поменять имя переменной в имплементации к примеру — вам не нужно будет ребилдить, и каким-то образом афектить «потребителя» абстракции — а при имплементации — придется.
не могу понять почему. Простой пример, в DI в аспнете, когда сервис регистрируешщь, меняешь одну иплементацию на другую, при этом все сервисы, которые юзали ту имплементацию. не нуждаются в рефакторинге, фиксинге и т.д. Даже при билде, они билдится не будут.
Баг в абстракции — не проблема абстракции, а проблема разработчиков — это не делает её — плохой. Я просто не до конца понял. что за фейковые страницы, что там и как надо было парсить.