Никуда она не денется. Не важно, где интерфейс, если интерфейса нет — код не скомпилируется.
Так если интерфейса нет — нету и абстракции. В таком случае, можно говорить, о зависимости метода, следовательно класса, следовательно компонента от локальной переменной.
Хотя, если так все сложить, как вы сказали — действительно зависимость будет. Но причин для изменения абстракции меньше — нежели имплементации. Абстракция стабильнее, именно поэтому зависимость на ней, а не на деталях реализации. Об этом, к слову, автор книги тоже говорит.
Почему же, вполне объективный. Наличие ресурсов — это объективный фактор.
Вернемся обратно к аналогии с домом и квартирой, от количества ресурсов, сам дом и квартира лучше не станут, или хуже. Они уже такие, какие есть.
«независимость суждений, мнений, представлений и т.п. от субъекта, его взглядов, интересов, вкусов, предпочтений и т.д. (противоположность — субъективность). О. означает способность не предвзято и без предрассудков вникать в содержание дела, представлять объект так, как он существует сам по себе» с словаря — ключевое слово
объект так, как он существует сам по себе
. Дом, САМ ПО СЕБЕ, а не в контексте сколько у вас есть бюджета.
Я так понимаю, вы на нарушение CCP забили? Оказался неважный принцип?
как по мне, там нету виолейшна, сервис один, в себе имеет логику, которая связанна с полнотекстовым поиском.
Ну да, от других слоев он теоретически независим. И что?
Независимость слоев — это тоже архитектура. Она дают простоту, изолирует один слой от другого, делает независимость одного слоя от другого, и логически связывает логику в одном. слое.
Если я не могу его купить, он для меня хуже. Аналогично, если бизнес не можете себе позволить архитектуру, значит, эта архитектура хуже для этого бизнеса, чем другая.
Ну так вы хотите получить объективный ответ на субъективный вопрос. Да, вашем случае хуже, в другом может быть лучше. Как вы хотите получить объективную характеристику в субъективном вопросе.
Вы мне хотите сказать, что у класса Some нет явной зависимости от интерфейса IDependency?
а вы в том же неймспейсе оставьте интерфейс — и не будет зависимости.
Вот только и домен, и инфраструктура имеют явную зависимость от этой абстракции. А это именно то, о чем я вас спрашивал.
Инфраструктура — имеет, домен нет. Домен независим от остальных лееров при этом.
Отменяет, в том-то и дело. Потому что вы поменяете то, что раньше люди узнали сквозь вашу абстракцию.
если действительно важно так знать, что-то об имплементации — об этих деталях можно оповестить людей. Если абстракции не делать, это никак не улучшит ситуацию. Все равно придется людей оповестить, что теперь то не юзайте, юзайте это.
Аналогично и со стороны пользователя: вся видимая простота абстракции сохраняется ровно до того момента, пока мне не нужна конкретная специфика поведения
Ну пока она не нужна — это работает. Если становиться нужна, ну значит такая сложилась ситуация, подставить другую имплементацию под интерфейс — все равно легче, нежели лазить и барахтаться в имплементации.
Отменяет, в том-то и дело. Потому что вы поменяете то, что раньше люди узнали сквозь вашу абстракцию.
По поводу этого — можно пожалуйста пример, когда у вас такая ситуация возникала.
Вот это и ответ на (ваш же) вопрос «кто сказал, вообще не знать о деталях реализации?». Вы сказали. Потому что вы говорите, что важно стремиться к тому, чтобы не знать о деталях реализации. Следовательно, когда я получу абстракцию, написанную по этим правилам, у меня будет минимум (в пределе — ноль) информации о реализации. А это то, что меня не всегда устраивает.
Ну если не устраивает — так узнайте немного больше. Если это важно в ваших реквайрментах. Может быть такое, что это знать не обязательно. Так или иначе, простоту и легкость в изменении это не отменяет
А разве можно считать хорошим нерентабельный подход?
Конечно, хорошесть определяеться ресурсами. Или вы хотите сказать, что к примеру огромный дом, где то в центре города хуже, старой обшарпаной квартиры, только потому, что он дороже? Нет — он по многим признакам лучше будет, вопрос в деньгах.
Вы опять переводите тему. Нет, не касательно «зависимости фидбека и артиклов». Меня интересует только выделенный вами микросервис поиска, который — в вашей декомпозиции! — нарушает CCP. Про фидбек поговорим потом.
Окей уберем фидбек, есть сервис, который отвечает только за артиклы(полнотекстовый поиск), где здесь виолейшн? Пришел запрос на вебсервис, пошел на абстракцию серч енджайна — вернул данные, где тут виолейшн ССP?
Вы мне хотите сказать, что код, использующий интерфейс, не имеет явной зависимости от этого интерфейса?
Да. Таким образом и строится архитектура по ДДД, абстракция репозитория в домене, и домен неимеет явных зависимостей на инфраструктуру.
Я еще раз повторю, мне не сложно: мы. говорим. не. про. фидбек. Мы говорим про один микросервис поиска по статьям.
А теперь вопрос — зачем мне это? Зачем мне «независимая разработка» для функциональности размером в десять строк кода?
ну тут мы говорим о рентабельности того или инного подхода, а не о том, что он плохой.
Касательно зависимости фидбека и артаклов. Окей, вы предлагаете иметь все в одной сборке. Теперь предположим, у вас появился сервис юзеров, там тоже нужно делать фидбек(слать меседж в какой-то екстернал сервис). Эта логика уже есть в артиклах, вы предлагаете это копипастить, или же юзеры теперь будут зависим компонентом от артиклов?
Для чего именно «того»?
для того, чтобы убрать явные зависимости, и сделать компонент независимым от деталей реализации.(в статье есть картинка) — это работает на масштабах объекта, компонента, и сервисов в целом.
Потому что нормальная единица развертывания для asp.net-сервиса — это сервис целиком, а не отдельные сборки внутри него. Если вы хотите подменять сборки по отдельности, вам придется сколхозить собственный набор механизмов доставки и обновления.
Можно это сделать через РЕСТ, объявить фидбек, как интернальный микросервис, и все делать через него, и мы сможем независимо деплоить его.
Говорят, что information hiding — одна из задач абстракции. Нет?
но кто сказал, что это идеально возможно во всех случаях. Тут скорее важно стремление к этому. есть много вообще полезных рекомендаций в жизни, но кто сказал, что их возможно постоянно и на 100% додерживаться?
В какой момент гарантированно произойдет физическая запись этих байтиков на носитель, и какие условия нужны для выполнения этой гарантии?
Я точно сказать не могу, я же это не писал. Я думаю, что при том, если все системы пк будут в норме. Конечно есть возможность бага, но она исключительно мала, и легче фиксится, благодаря абстракциям,
Теперь у вас появился контракт между этим компонентом и вашим. Компонентов стало больше, контрактов стало больше, но проблема никуда не исчезла.
но через инвертирование зависимостей все стает независимым, независимо деплоябельным, и независимо девелопабильным. Так или иначе эти же контракты остаются, будучи в одном компоненте.
Но вообще, конечно, нельзя. Деплоить надо релиз целиком, потому что REP
Почему?? если н е устраивает фидбек, или его нужно слать ещё в одно место, к примеру, что мешает написать эту логику, и задеплоить только этот микросервис??? Именно поэтому он и был разделён, по этому же принципу, что бы так можно было сделать. В случае вашем же, редеплоить пришлось бы и артиклы, просто потому, что архитектура хуже бы была, а почему? потому что этот принцип (REP) не соблюден.
На уровне классов и компонентов этот принцип называется SRP, и там ровно те же проблемы, просто с другими словами.
А главное, какая мне разница, что она гарантирует? Мне важно, что я не могу просто сделать вид «это абстракция, что за ней — мне не важно», я должен помнить детали конкретных реализаций. Что хуже, иногда абстрация построена так, что я не могу выяснить, какая там реализация (что, в общем-то, еще хуже).
Так а кто сказал, вообще не знать о деталях реализации? Вы скорее всего будете знать, как в общем что-то устроено, описывая очередную имплементацию. Только вот работать с этим проще, при росте проекта, и проще заменить на что-то другое при этом.
… и даже этого она не гарантирует.
Ну почему же? Так, как и с TCP, есть условия, при которых есть гарантии. Так или иначе, имплементация не дает тоже никаких гарантий. Единственное, что дает гарантии в этом мире — это то, что мы все умрем. Если вы хотите гарантий — вам не к абстракциям.
Значит, не знаю, почему вы утверждаете, что это плохо.
в таком случае я объяснил, почему, по моему, это плохо. Да и не только по моему.
Я говорил, что все — текут. Это не отменяет того, что даже текущие абстракции могут быть полезны, просто надо каждый (каждый!) раз помнить, что та абстракция, на которую ты сейчас встал, может потечь и потопить тебя.
Опять таки, пока что, не вижу утечки у IP & LINK лейера, и ОС. Даже в примере с SSD & HDD, разве ОС гарантирует скорость. Она гарантирует, что если система рабочая, она запишет и считает данные
Никуда она не пропадает, она все так же в том же компоненте. В другом классе, но в том же компоненте.
Ну в данном случае, я бы реализовал посыл по нетворку какого-то меседжа в отдельной библиотеке, а это — компонент, потому что ее можно отдельно задеплоить.
Тут я за компонент забыл, но вспомнил. Даже на уровне классов и методов принципы остаются рабочими. Пропадает только фича независимого деплоинга.
вот эта ответственность и всплывает, когда набросать все в один метод. Если посыл фидбека вынести как отдельный клас с интерфейсом — эта ответственность пропадает. По серч енджайну, все это можно запихнуть в единую абстракцию аля (дай мне статьи по такому слову), и все, а в имплементации мы можем и сфинкс тогда юзнуть. Код контроллера примерный:
public async Task<List<Article>> GetArticlesAsync(string searchWord){
var articles = _engineAbs.GetArticlesBySearchWord(searchWord);
_externalInteractor.SendFeedback();
}
Теперь изменения в посыле фидбека никак не влияет на гет статей.
А откуда вы взяли эту альтернативу? Я ее не озвучивал.
но вы сказали «что плохого в том», когда я написал вариант засунуть в контролер логику серч енджайна, бд, логирования и конвертацию моделей.
В статье, которую вы проглядели.
там только за TCP. С этим, пожалуй пока соглашусь.
Как минимум — application и transport. И я хорошо знаю, что нельзя просто взять и заменить tcp на udp — можно и связность потерять.
ну да, апликейшн лейер будет зависеть от транспортного, потому что две разные имплементации транспортного в корне разные. Но вы глядите глубже, вам же не приходилось залезать в LINK & IP лейер?
Неа, первый фидбек пишется в момент прохождения запроса в полнотекстовый поиск (чтобы сам факт запроса фиксировать).
тогда прошу прощения, я имел в виду фидбек — как отдельная сущность отзыва клиента о системе, без контекста артиклов.
Вот видите. Вы все сделали по вашим правилам, а архитектура все равно «не релевантная».
Но такого разговора не было, никто ничего не решил — поэтому ещё не не релевантная. Просто когда обсуждали проект, в котором я — приняли, например, решение писать на микросервисах — и сейчас я понимаю, что если бы не приняли — были бы сложности.
Там, где каждый ваш компонент имеет больше одной причины для изменения.
И какая там причина изменения кроме причины изменения связанная с серч енджайном?
Вообще-то, она увеличится, потому что вместо обращения к одному компоненту будет обращение к двум, а пересечение границы компонента — это дорого.
в контексте задачи — это все равно два различных запроса. Какая разница обращаться на два сервака, или на один? Или вы хотели впихнуть в один запрос и сохранение фидбека и доставание артиклов??
… и если они оценят иначе, то ваша архитектура перестанет быть правильной, и станет правильной какая-то другая?
нет, она станет не релевантная в данном случае.
Мне, конечно, нравится, как вы элегантно проигнорировали нарушение CCP в вашей декомпозиции (а при этом продолжаете говорить, что нарушение SRP в классе — это плохо).
вполне может быть — я не архитектор, и когда привел пример, я не советовался вообще ни с кем, а с потолка взял то, что первое в голову пришло. Где же там нарушение?
… вот только он взял и просел по скорости на порядок, а так да, трогать ничего не надо.
ну так поменять будет проще, из-за абстракции, ибо не тонешь в 100500 строках асма.
Ключевое — как-то.
Вы в этом участвовали? что точно знаете, что как-то? Так или иначе — получилось. Поэтому НЕ ВСЕ — текут. Я думаю можно сделать максимально не-текущие абстракции, вопрос в релевантности и денежных запасах.
Забыли латентность, а это для пользователя важнее всего.
А как это повлияет на латентность?
Не «когда», а «если». Если вы доживете до момента, когда проект начнет расти, а не погрязнете в разработке согласованного деплоя, системы коммуникации, протокола обмена с клиентом и прочих мелочей, которые вас тормозят.
Я думаю это уже совсем другой вопрос. Естественно, для этого архитекторы собираются с ПМами и т.д., что бы оценить риски, и стоит ли делать вот так и все сразу, или что-то пока что оставить на потом.
(забавно при этом, что выше вы предлагали другую декомпозицию, но уже про нее забыли)
имелась в виду эта, может я не правильно выразился
Окей, но плюсы то все ровно есть, и сложность, и изменение, не нравиться SSD — юзни HDD, а вызывающий код трогать не надо.
Проще говоря, текущая абстракция — это когда то, что за абстракцией все равно влияет на вас, как на пользователя
Ну окей, но от лейера IP & LINK абстрагороваться то получилось. И работает, ещё ни разу не слышал что бы один из них делал что-то некорректно. И их может юзать как TCP так и UDP, и их не заботит как он устроен.
Хотя, если так все сложить, как вы сказали — действительно зависимость будет. Но причин для изменения абстракции меньше — нежели имплементации. Абстракция стабильнее, именно поэтому зависимость на ней, а не на деталях реализации. Об этом, к слову, автор книги тоже говорит.
Вернемся обратно к аналогии с домом и квартирой, от количества ресурсов, сам дом и квартира лучше не станут, или хуже. Они уже такие, какие есть.
«независимость суждений, мнений, представлений и т.п. от субъекта, его взглядов, интересов, вкусов, предпочтений и т.д. (противоположность — субъективность). О. означает способность не предвзято и без предрассудков вникать в содержание дела, представлять объект так, как он существует сам по себе» с словаря — ключевое слово . Дом, САМ ПО СЕБЕ, а не в контексте сколько у вас есть бюджета.
как по мне, там нету виолейшна, сервис один, в себе имеет логику, которая связанна с полнотекстовым поиском.
Независимость слоев — это тоже архитектура. Она дают простоту, изолирует один слой от другого, делает независимость одного слоя от другого, и логически связывает логику в одном. слое.
а вы в том же неймспейсе оставьте интерфейс — и не будет зависимости.
Инфраструктура — имеет, домен нет. Домен независим от остальных лееров при этом.
Ну пока она не нужна — это работает. Если становиться нужна, ну значит такая сложилась ситуация, подставить другую имплементацию под интерфейс — все равно легче, нежели лазить и барахтаться в имплементации.
По поводу этого — можно пожалуйста пример, когда у вас такая ситуация возникала.
Окей уберем фидбек, есть сервис, который отвечает только за артиклы(полнотекстовый поиск), где здесь виолейшн? Пришел запрос на вебсервис, пошел на абстракцию серч енджайна — вернул данные, где тут виолейшн ССP?
Да. Таким образом и строится архитектура по ДДД, абстракция репозитория в домене, и домен неимеет явных зависимостей на инфраструктуру.
в этом же ответе выше.
Касательно зависимости фидбека и артаклов. Окей, вы предлагаете иметь все в одной сборке. Теперь предположим, у вас появился сервис юзеров, там тоже нужно делать фидбек(слать меседж в какой-то екстернал сервис). Эта логика уже есть в артиклах, вы предлагаете это копипастить, или же юзеры теперь будут зависим компонентом от артиклов?
для того, чтобы убрать явные зависимости, и сделать компонент независимым от деталей реализации.(в статье есть картинка) — это работает на масштабах объекта, компонента, и сервисов в целом.
Можно это сделать через РЕСТ, объявить фидбек, как интернальный микросервис, и все делать через него, и мы сможем независимо деплоить его.
Я точно сказать не могу, я же это не писал. Я думаю, что при том, если все системы пк будут в норме. Конечно есть возможность бага, но она исключительно мала, и легче фиксится, благодаря абстракциям,
но через инвертирование зависимостей все стает независимым, независимо деплоябельным, и независимо девелопабильным. Так или иначе эти же контракты остаются, будучи в одном компоненте.
Почему?? если н е устраивает фидбек, или его нужно слать ещё в одно место, к примеру, что мешает написать эту логику, и задеплоить только этот микросервис??? Именно поэтому он и был разделён, по этому же принципу, что бы так можно было сделать. В случае вашем же, редеплоить пришлось бы и артиклы, просто потому, что архитектура хуже бы была, а почему? потому что этот принцип (REP) не соблюден.
для того придумали Dependency Inversion.
Так а кто сказал, вообще не знать о деталях реализации? Вы скорее всего будете знать, как в общем что-то устроено, описывая очередную имплементацию. Только вот работать с этим проще, при росте проекта, и проще заменить на что-то другое при этом.
Ну почему же? Так, как и с TCP, есть условия, при которых есть гарантии. Так или иначе, имплементация не дает тоже никаких гарантий. Единственное, что дает гарантии в этом мире — это то, что мы все умрем. Если вы хотите гарантий — вам не к абстракциям.
Опять таки, пока что, не вижу утечки у IP & LINK лейера, и ОС. Даже в примере с SSD & HDD, разве ОС гарантирует скорость. Она гарантирует, что если система рабочая, она запишет и считает данные
Ну в данном случае, я бы реализовал посыл по нетворку какого-то меседжа в отдельной библиотеке, а это — компонент, потому что ее можно отдельно задеплоить.
Тут я за компонент забыл, но вспомнил. Даже на уровне классов и методов принципы остаются рабочими. Пропадает только фича независимого деплоинга.
Если спросили — значит не знаете, или как?
Теперь изменения в посыле фидбека никак не влияет на гет статей.
там только за TCP. С этим, пожалуй пока соглашусь.
ну да, апликейшн лейер будет зависеть от транспортного, потому что две разные имплементации транспортного в корне разные. Но вы глядите глубже, вам же не приходилось залезать в LINK & IP лейер?
Но такого разговора не было, никто ничего не решил — поэтому ещё не не релевантная. Просто когда обсуждали проект, в котором я — приняли, например, решение писать на микросервисах — и сейчас я понимаю, что если бы не приняли — были бы сложности.
И какая там причина изменения кроме причины изменения связанная с серч енджайном?
между какими уровнями?
Пример IP лейер стэка — где здесь утечка? Может это и так, я не спорю, просто я пока её не вижу, и хотелось бы видеть
нет, она станет не релевантная в данном случае.
вполне может быть — я не архитектор, и когда привел пример, я не советовался вообще ни с кем, а с потолка взял то, что первое в голову пришло. Где же там нарушение?
Вы в этом участвовали? что точно знаете, что как-то? Так или иначе — получилось. Поэтому НЕ ВСЕ — текут. Я думаю можно сделать максимально не-текущие абстракции, вопрос в релевантности и денежных запасах.
А как это повлияет на латентность?
Я думаю это уже совсем другой вопрос. Естественно, для этого архитекторы собираются с ПМами и т.д., что бы оценить риски, и стоит ли делать вот так и все сразу, или что-то пока что оставить на потом.
имелась в виду эта, может я не правильно выразился
Ну окей, но от лейера IP & LINK абстрагороваться то получилось. И работает, ещё ни разу не слышал что бы один из них делал что-то некорректно. И их может юзать как TCP так и UDP, и их не заботит как он устроен.