Коротко о главном: Clean Architecture, Robert C. Martin

Это будет рассказ о впечатлении о книге, а также будут рассмотрены некоторые понятия и знания, которые, благодаря этой книге, были изучены

Архитектура


Можете ли вы, читая эту публикацию, дать четкий ответ на вопрос, что такое архитектура? Что такое архитектура в контексте программирования и проектирования? Какую роль она играет? Достаточно много неясностей есть в этом термине. И вроде бы все понятно, но как-то абстрактно, и без точности. Мартин считает, и я с ним солидарен, что приложение имеет две составляющих:

  1. Поведение (behavior) — функции и задачи, которые программа (компонент, сервис) выполняет.
  2. Архитектура — этот термин в большей мере о изменении приложения.

Но даже, если приложение очень хорошо выполняет задачу, которую она должна выполнять, это совсем не значит, что оно имеет хорошую архитектуру. Архитектура — это не о поведении приложения. Архитектура — это о легкости изменяемости, архитектура — это о легкости развертывания, архитектура — это о независимости разработки. Архитектура — это о скорости, с которой понимание приходит к новому человеку в команде

И вот как строить эту архитектуру, как избавится от головной боли при маленьком изменении требований от PM’а, или от стейкхолдера: об этом и поведает книга

Об авторах


Перед тем, как что-либо говорить об этой книге, я хочу сказать немного о себе.
На данный момент я Strong Junior Developer, специализирующийся на разработке сервисов посредством ASP .NET CORE’а.

Я уже год работаю на одной “галерке”, и вроде бы по чуть-чуть справляюсь

Книгу я эту уже прочел 2 раза, и к чтению рекомендую всем:

  • разработчикам embeded систем;
  • фронт-эндщикам;
  • бэк-эндщикам;
  • и даже девопсам.

Вообщем всем, кто хоть как то связан с разработкой ПЗ, имеется в виду непосредственной разработкой разных там Сейлов и ПМ’ов сюда не учитываем (хотя тоже было бы полезно знать, почему дев бывает тратит в 2 раза больше времени на задачу), советую прочесть эту книгу.
И сейчас я попробую аргументировать, почему я так считаю

Немного об авторе этой книги ( потому что для меня авторитет пишущего играет большую роль). Я думаю вы меня поймете, хоть это не всегда правильно, но если вам что-то говорит авторитетный человек в сфере — вы проявляете намного больше доверия к сказанному им. Например, я думаю вы больше поверите в диагноз, который вам ставит врач, нежели от какой-то человек из толпы (погугливший симптомы)

Роберт Мартин — он же Анкл Боб (дядюшка Боб) — работает в сфере программирования, причем разных систем (от вебсервисов до ембедит систем), с 1970 года. является техническим консультантом и архитектором, писал в разные технические журналы, сам по себе очень опытный программист, и человек который играл одну из ключевых ролей при создание всем известных SOLID принципов (можно сказать создатель). Так же, хочется добавить, что мне эту книгу посоветовал мой тимлид с 15+ опытом работы

О книге


Зависимости


Перед прочтением книги, я достаточно много статеек на том же Хабре читал, где фигурировало такое слово, как “зависимость”. Что это такое, кто от кого зависим, что конкретно значит “зависеть”, и как какой то класс может зависеть от кого-то?

И вот по мере прочтения книги я усвоил два момента:

Зависимость — это термин, значащий, что какой-то класс (компонент, сервис) знает о каком-то другом классе (компоненте, сервисе), и это знание на уровне кода определяется (сейчас джависты, шарписты, сишники меня поймут) определенным импортом неймспейса. Иными словами: есть у вас класс А с неймспейсом Default.Classes и класс B Another.Classes. Так вот, если в сорс коде класса А будет фигурировать using Another.Classes; — то это значит, что класс А зависит от класса B.
Чтобы понять по схеме, где зависимый класс, а где нет — смотрите на направление стрелки: в 1) стрелка будет указывать от класса А в направлении класса B. Это значит, что класс B более независимый, чем класс А. И изменения в классе А, никакого “ущерба” классу B не нанесут

image

SOLID


Одной из основной причины, которая была для меня к прочтению этой книги — это объяснение SОLID принципов из первоисточника, потому что дядя Роб разрабатывал эти принципы и можно сказать, благодаря ему мы слышим это название — SOLID.
Для тех, кто не в курсе — эти принципы говорят и советуют дизайнить свои приложения в соответствии с 5 правилами:

S — SRP (Single responsibility principle)
O — OCP (Open-closed principle)
L — LSP (Liskov substitution principle)
I — ISP (Interface segregation principle)
D — DIP (Dependency Inversion principle)

Все эти принципы могут быть применены на уровне классов и объектов, на уровне модулей и компонентов и на уровне лееров (сервисов).

Если вы считаете что Single responsibility principle — это про то, что класс, или же модуль должен делать только что-то одно — то вам обязательно нужно прочитать хоть бы главу про Солид. Ибо то определение, что дано выше — это следствие, но никак не определение самого принципа

О Dependency Inversion


Особое внимание хочу обратить на объяснение Dependency Inversion Principle (тот, что D из SOLID’a). По ходу прочтения книги, я понимал, это не просто принцип, это ещё механизм и инструмент, с помощью которого, вы можете менять направление ваших зависимостей, и делать, к примеру, бизнес логику (DOMAIN) независимой от деталей реализации Data access layer’а (DAL’a)

image

Хоть сам принцип на ряду с остальными в СОЛИД значит немного не то, что механизм, сам механизм используется на протяжении всей книги, и это один из основных методов инвертировать и менять направление ваших зависимостей, который кстати используется при DDD

О принятии архитектурных решений


Очень часто в книге будет упоминается принцип о принятии важных архитектурных решений: о том, какую БД использовать, какой фреймворк использовать, какую библиотеку подключать, что использовать как поисковой движок и т.д

Так вот, автор считает: вы должны КАК МОЖНО МЕНЬШЕ принимать такого рода решения. Ибо requirements могут изменяться, ограничения по perfomance’у тоже, сама поведенческая составляющая имеет тенденцию меняться. В процессе разработки какие-то решение может показаться менее эффективным нежели другое, менее удобным нежели другое. И сила твоей архитектуры будет определять, насколько быстро и безболезненно ты сможешь заменить одну технологию на другую (об этом кстати твердит OCP).

Например, внезапно, вы решите использовать вместо Postgresql MongoDb, или вообще файлики, или использовать mock’нутые данные, операции с которыми будут производится в памяти. И при некоторых условиях — это может заставить переписать почти всю логику.

Чтобы таких ситуаций не возникало, мы можем использовать некоторые механизмы, которые будут максимально далеко отодвигать время принятия решения. Один из этих механизмов — абстракция.

Отсылки на DDD


DDD — Domain Driven Design — подход к разработке сервисов с сложной бизнес логикой, критической к изменениям, который направленный на максимальной понимание руководящих должностей проекта (PMs, Sale managers etc), с рядовыми гребцами. То есть, что бы между все членами проекта был ubiquitous language, и каждый мог понять другого, и чтобы все мыслили в одном domain’е с одними и теме же бизнес правилами.

Если вы — приверженец DDD, или хотите быть таковым, или вы что-то в этом не понимаете, но хотите понимать — книга обязательна к прочтению, особенно вторая часть книги.

Здесь автор объясняет о существование Dependency Rule, и почему, следуя ему — вы будете строить правильную архитектуру приложения. Почему зависимости должны следовать в направлении к High Policy компонентам, почему домен (High Policy компонент) должен быть независим от инфраструктуры и как это упростит вам деплоймент и девелопинг

image

Абстрагирование


Дядя Роб, также рассказывает о том, как детали реализации могут навредить вашей системе, и не дать эволюционировать без боли в дальнейшем.

Помните!
БД — это деталь реализации
Клиенты (Web, Mobile, etc) — детали реализации
Фреймворки — это деталь реализации

От этого всего нужно максимально абстрагироваться и не зависеть, используя выше описанный Dependency Inversion с интерфейсами и абстракциями, Dependency Rule и прочие механизмы

Методы построения модулей


Этот раздел мне понравился особо сильно, как разработчику сервисов на ASP .NET CORE’е. Ибо здесь рассказываются о методологиях построения единой архитектуры сервиса из готовых компонентов.

Роберт описал 4 возможных схемы разделения слоев.

Он дал понять почему так часто используемый механизм 3-х слоевой архитектуры: UI (controllers), Services (Domain), DAL (Database) — достаточно плох по сравнению с другими. Я видел не очень много проектов, но в каждом, например микро-сервисе, на бэк-энде, используется именно трех-слоевая архитектура.

Так же, достаточно часто, используется архитектура один-компонент-один-сервис. В целом они обе неплохие, но она имеет достаточно много минусов, в сравнении к примеру, как строится архитектура при использовании DDD, особенно при критических к изменению, и сложных сервисов.

В общем, вот и подошел к концу этот обзор на книгу. Сама книга мне очень понравилась, не жалею о прочитанном, спасибо автору. Вам, дорогие читатели, спасибо за внимание, не судите строго — эта публикация, основанная на впечатлении от книги и моем личном энтузиазме

UPDATE 1.0

В ходе дискуссий, можно понять, что ВНЕЗАПНАЯ, и ЛЕГКАЯ смена хранилища — будет не легка, так, или иначе. В некоторых случаях, даже очень болезненная, и все же, абстракция и инкапсуляция доступа к хранилища, сомнительно, что сделает положение хуже, а скорее немного лучше, как минимум за счет независимости изменяемого компонента от остальных.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 228

    +5
    Например, внезапно, вы решите использовать вместо Postgresql MongoDb, или вообще файлики, или использовать mock’нутые данные, операции с которыми будут производится в памяти. И при некоторых условиях — это может заставить переписать почти всю логику.

    Чтобы таких ситуаций не возникало, мы можем использовать некоторые механизмы, которые будут максимально далеко отодвигать время принятия решения. Один из этих механизмов — абстракция.

    Угу, абстракция, ага. А теперь давайте посмотрим на этот конкретный пример: вот вы хотите сделать такую систему, в которой не важно, что вы используете — СУБД, или внезапно ДОБД, или внезапно, ключ-значение (я бы хотел, конечно, посмотреть, на проект, в котором это происходит внезапно). И за какой же абстракцией вы спрячете все эти различия, чтобы замена произошла незаметно и безболезненно?


    Это все к тому, что красивые фразы "это все детали реализации" обычно так и остаются красивыми фразами, потому что суровая реальность намного сложнее, чем простые примеры.

      0
      Полностью согласен с вами, не всегда можно просто сменить способ хранение данных. Имеется в виду скорее переход с однотипных баз данных, например c Postgresql на MSSQL и т.д.

      Даже в случае key-value, я думаю, это нужно инкапсулировать доступ к данным так или иначе.
        +1

        Ну то есть первый же попавшийся мне на глаза пример, который вы показываете, как пример "хорошей архитектуры", невозможен.


        Так какие же полезные (и при этом не-тривиальные) советы дает в этом вопросе книга?

          –1
          Я думаю, здесь многое зависит от самого проекта, естественно переход к новому способу хранения данных — это всегда боль, вопрос будет в том насколько это будет больно. Как минимум совет инкапсулировать доступ к данным через какую-нибудь абстракцию — рабочий, и малость снизит боль перехода. + к этом будет простота в тестировании. А общего и безболезненного солюшна нету, я думаю. Поэтому и в конце автор говорит, и в книге есть его личные примере с его опыта, что такого рода архитектурные решения нужно принимать как можно позже — что бы свести к минимуму вероятность изменения способа хранения данных
            +1
            Я думаю, здесь многое зависит от самого проекта

            Так чему же тогда учит эта книга? "Думать"?


            Как минимум совет инкапсулировать доступ к данным через какую-нибудь абстракцию — рабочий

            Это проходит по категории "тривиальный". Чтобы он стал не-тривиальным, нужно иметь критерии, отличающие "хорошую" абстракцию от "плохой".


            такого рода архитектурные решения нужно принимать как можно позже

            А код-то как писать, если не принимать такие архитектурные решения рано?

              0
              Это проходит по категории «тривиальный». Чтобы он стал не-тривиальным, нужно иметь критерии, отличающие «хорошую» абстракцию от «плохой».

              Был бы рад, если бы вы скинули литературы, которая учит отличать хорошую от плохой.

              А код-то как писать, если не принимать такие архитектурные решения рано?


              Ну в моем понимании, ваше приложение должно иметь какую-то свою логику (бизнес логику), и начать нужно именно с ней, а не имплементить доступ к данным сходу — вот о чем говорит автор.

              Кроме того, книга эта я бы не сказал что для опытных ребят, это скорее для новичков вроде меня, где разложенные и разжеванные основы
                +1
                Был бы рад, если бы вы скинули литературы, которая учит отличать хорошую от плохой.

                Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice, если я ничего не путаю за давностью лет.


                Ну в моем понимании, ваше приложение должно иметь какую-то свою логику (бизнес логику), и его нужно начать именно с ней

                И как предлагается начать с бизнес-логики, если она работает с данными из БД и других внешних источников, своим входом имеет UI, и выходом — тоже UI?

                  0
                  За авторов спасиб)

                  И как предлагается начать с бизнес-логики, если она работает с данными из БД и других внешних источников, своим входом имеет UI, и выходом — тоже UI?

                  сейчас скажу в контексте только бэк-енда. Есть такая книжечка про microservices & DDD от майкрософтов, возьму пример их же проект EShopOnContainers, сервис Ordering. В домене есть некоторые Aggregate и Entities. Можно начать с них, обдумать что как и с чем должно взаимодействовать, описать логику, а в самом поведении использовать абстракцию Repository без implementation. Как-то так. Если прям нужно тестить — ну можно in memory implementation в IoC подставить. Можно так же заняться Application Layer.
                    +1
                    а в самом поведении использовать абстракцию Repository без implementation.

                    Стоп. Вот же оно ваше "архитектурное решение", использовать паттерн repository, да еще и с конкретным интерфейсом наверняка. А вы говорите "отложить на потом". Да, а потом вы возьмете СУБД, и поймете, что ее нельзя запихнуть в тот интерфейс, который вы на первом этапе нарисовали для репозитория, и что тогда?


                    Можно так же заняться Application Layer.

                    А что такое в этом контексте application layer, и почему его написание не приводит к принятию архитектурных решений?

                      0
                      Стоп. Вот же оно ваше «архитектурное решение», использовать паттерн repository, да еще и с конкретным интерфейсом наверняка. А вы говорите «отложить на потом». Да, а потом вы возьмете СУБД, и поймете, что ее нельзя запихнуть в тот интерфейс, который вы на первом этапе нарисовали для репозитория, и что тогда?


                      Я думаю, что есть организация данных — которая сама по себе навязывает способ хранения данных. Сам я, к примеру с NoSql не работал, но мне кажется, что в том конкретном случае логично понятно, что все связи в сервисе было бы проще организовать с помощью SQL-based структуре хранения данных. И если например бизнес логика навязывает один способ хранения данных как подходящий и иной — как не подходящий, может стоит использовать подходящий, а не менять бизнес логику из-за того, что работа с данными в них не вписывается?

                      Что в таком случае бы вы сделали? Вы предлагаете от способа хранения данных плясать и писать бизнес логику?

                      А что такое в этом контексте application layer, и почему его написание не приводит к принятию архитектурных решений?


                      Это уже DDD штука, если в двух словах — Layer, который в себе имеет Use Case'ы, делегирует все запросы с UI на Домен, и обратно и т.д.
                        0
                        Я думаю, что есть организация данных — которая сама по себе навязывает способ хранения данных.

                        Так, и? Что с решениями-то делать?


                        том конкретном случае логично понятно, что все связи в сервисе было бы проще организовать с помощью SQL-based структуре хранения данных.

                        "Логично понятно что" — это вы приняли (крупное!) архитектурное решение ("мы будем использовать реляционную модель") и даже не заметили этого.


                        И если например бизнес логика навязывает один способ хранения данных как подходящий

                        Подождите, вы же в статье пишете "БД — это детали реализации".


                        Вы предлагаете от способа хранения данных плясать и писать бизнес логику?

                        Я предлагаю как-то привести в соответствие заявления, которые вы делаете в статье, и реальную практику, которая в ваших же примерах этим заявлениям не соответствует.


                        Это уже DDD штука, если в двух словах — Layer, который в себе имеет Use Case'ы, делегирует все запросы с UI на Домен

                        А у вас Use Case никак не зависят от того, каким образом используется домен? Проще говоря, use case для человека перед пользовательским интерфейсом, и для внешней системы, работающей через API, не отличаются?

                          0
                          Так, а кто говорил, что эта книга подходит под все, и волшебная таблетка от всего. Так не бывает — есть частные случаи. К сожалению, я не имею того опыта, что бы спорить о практике. В тех же примерах личного жизненного опыта автора он описывал как абстракция над доступом к данным помогла избежать некоторых проблем, точнее помогла не делать лишней работы, можете лично с ними ознакомится.

                          В примере конкретно Майкрософтов, DDD навязывает некоторые решения, как, к примеру, о интерфейсе репозитория — потому что, это — паттерн, который и был создан для абстрагирования от доступа к данным. И он имеет свой определенный интерфейс.

                          Рассмотрим к примеру апдейт того же самого ордера. В репозитории. Для этого есть соответственный метод на GetOrder(), и если его не будет, то и апдейта не будет, и если способ хранения данными не позволяет достать этот ордер — то значит он не подходит. То же самое с методом репозитория на сохранение всех изменений, который призван для того, что бы в случае изменений не одной ентити, а нескольких в пределах одного агрегата — сделать это одной транзакцией (либо все, либо ничего). Это, как я понимаю. реквайрмент бизнеса, и если же такой метод не может быть представлен каким-то способом хранения данных, значит он не подходит для этой бизнес логики. Именно поэтому ДДД и говорит о том, что полного соответствия ентити в БД с ентетей из домена может и не быть.

                            +2
                            Так, а кто говорил, что эта книга подходит под все, и волшебная таблетка от всего.

                            А для чего она подходит и от чего она помогает?


                            DDD навязывает некоторые решения, как, к примеру, о интерфейсе репозитория — потому что, это — паттерн, который и был создан для абстрагирования от доступа к данным

                            Я про это и говорю: вы, на самом деле, принимаете множество архитектурных решений на самом старте (начав, кстати, с решения исползовать DDD). Так что же, собственно, вы предлагаете отложить на потом?


                            Рассмотрим к примеру апдейт того же самого ордера. В репозитории.

                            А почему в репозитории-то? Почему вы другие паттерны не рассматриваете?


                            Это, как я понимаю. реквайрмент бизнеса

                            Неа, это то, как вы это какое-то требование бизнеса интерпретировали. Совершенно не факт, что бизнесу нужна именно такая транзакционность, как вы описываете.


                            Именно поэтому ДДД и говорит о том, что полного соответствия ентити в БД с ентетей из домена может и не быть.

                            Подождите, сначала вы говорите, что способ хранилища данных должен полностью соответствовать требованиям бизнеса, а потом вы говорите, что именно поэтому "полного соответствия быть не может". Где-то что-то перепутано.

                              0
                              Подождите, сначала вы говорите, что способ хранилища данных должен полностью соответствовать требованиям бизнеса, а потом вы говорите, что именно поэтому «полного соответствия быть не может». Где-то что-то перепутано.

                              Не много не так выразился: может допускаться, что будут различия между моделью БД и моделью Домена. Это делается, на примере того же EShopOnContainers, как раз для абстрагирования от деталей хранилища. У ордера(может и не у него, но не суть, в какой-то ентите) должен быть адрес. И этот адрес мы можем сразу организовать как член класса этого самого ордера, хотя прямой связи может и не быть в SQL(так оно и есть, ибо там это Value object), или же мы сможем с легкостью сделать по классике, через ещё одну таблицу в SQL и реляционную связь, либо же использовать NoSQL и поместить адрес прям в ордер. Можно вообще организовать бинарные файлы, Но фишка вся будет в том, что интерфейс репозитория как возвращал ордер с адресом — так и возвращает — вот такой маленький (идеализированный) пример, понятно, что есть случаи, когда так легко сделать не получится, опять же говорю, я этого и не отрицал — книга — не панацея от всего.

                              П.С. про легкость перехода с SQL на NOSQL или key-value, напишу апдейт, тут с вами согласен — легким этот переход не сделать, но все же, думаю, что если это будет инкапсулировано и абстрагировано по максимуму — это сделает переезд менее болезненным. У меня нету большого опыта, что бы знать какие ситуации бывают, и насколько это сложно, ибо сам такого опыта не имел. Конкретные техники, и как лучше абстрагироваться в том или ином случае — это уже не об этом книга, на то архитекторы и получают свои тысячи зеленью и едят сыры xD
                                +2
                                может допускаться, что будут различия между моделью БД и моделью Домена.

                                Может допускаться, да. И что? Как это помогает принимать решения?


                                И этот адрес мы можем сразу организовать как член класса этого самого ордера, хотя прямой связи может и не быть в SQL(так оно и есть, ибо там это Value object), или же мы сможем с легкостью сделать по классике, через ещё одну таблицу в SQL и реляционную связь, либо же использовать NoSQL и поместить адрес прям в ордер.

                                Угу, и во всех этих вариантах у вас будут разные гарантии целостности. Дада, те самые, про которые вы только что говорили как про бизнес-требования на транзакции. Вас это не волнует, нет?


                                книга — не панацея от всего.

                                Вы это уже говорили, и я спросил: а для чего же она полезна?


                                но все же, думаю, что если это будет инкапсулировано и абстрагировано по максимуму — это сделает переезд менее болезненным

                                Если все будет инкапсулировано и абстрагировано по-максимуму, вы можете так задолбаться в процессе разработки первой версии, что до переезда никогда и не дожить.


                                это уже не об этом книга

                                А о чем она тогда? Вы вроде пишете "И вот как строить эту архитектуру". Нет?

                                  0
                                  Угу, и во всех этих вариантах у вас будут разные гарантии целостности. Дада, те самые, про которые вы только что говорили как про бизнес-требования на транзакции. Вас это не волнует, нет?

                                  Ну так это и будет задача имплементации того репозитория, что бы при SaveChanges(), все осталось целостным, ну как мне кажется. Как я понял, фишка в том, что бы бизнес лейер об этом не думал в процессе выполнения какой-то логики

                                  Может допускаться, да. И что? Как это помогает принимать решения?

                                  это поможет какое-то время НЕ принимать решения.

                                  Вы это уже говорили, и я спросил: а для чего же она полезна?


                                  Ну как по мне набор базовых принципов, которых следует придерживаться что бы построить хотя-бы не неправильную архитектуру. Она не может покрыть всех случаев. И есть случаи, когда, мне лично, эти знания помогали в принятии одного из двух решений, не раз я видел подтверждение их в разного рода проектах. Тот же самый EShopOnContainers.

                                  Только общие принципы, и пару примеров из опыта самого автора. Почему вы хотите увидеть какую-то конкретику? Если вас интересует какую лучше абстракцию над данными выбрать — так нужно именно это искать статьи, книги, спикинги умных людей. Книга, как по мне, скорее введение в правильное строение, что бы вообще понимать, что будет хорошо, а что плохо.

                                  Так же, мне уже самому интересно, как тогда вообще строить доступ к бд, как строить абстракции над данными, или вообще не строить их? Приведите пару примеров, может личные рекомендации?
                                  Может вы лично сталкивались с проблемами переезда с одного способа хранения на другой — поделитесь тогда опытом
                                    0
                                    Ну так это и будет задача имплементации того репозитория, что бы при SaveChanges(), все осталось целостным, ну как мне кажется.

                                    Вы себе стоимость такой имплементации для нетранзакционной распределенной системы представляете?


                                    это поможет какое-то время НЕ принимать решения.

                                    Ну так можно просто не принимать никаких решений. Что мешает?


                                    Ну как по мне набор базовых принципов, которых следует придерживаться что бы построить хотя-бы не неправильную архитектуру

                                    Что такое "неправильная" архитектура, и как отличить ее от правильной? Гарантирует ли следование вашим "базовым принципам", что "неправильная" архитектура не получится?


                                    И есть случаи, когда, мне лично, эти знания помогали в принятии одного из двух решений,

                                    Как вы можете проверить, что принятые вами решения — правильные?


                                    Почему вы хотите увидеть какую-то конкретику?

                                    Потому что без конкретики это все бесполезно (и неоднократно описано).


                                    Книга, как по мне, скорее введение в правильное строение, что бы вообще понимать, что будет хорошо, а что плохо.

                                    Так что же будет хорошо-то? И что — плохо?


                                    Так же, мне уже самому интересно, как тогда вообще строить доступ к бд, как строить абстракции над данными, или вообще не строить их?

                                    Да как обычно: собирать требования, формулировать их, выбирать решения.

                                      0
                                      Вы себе стоимость такой имплементации для нетранзакционной распределенной системы представляете?


                                      Есть варианты, описаны в ещё одной книжке Designing Data-Intensive Applications.

                                      Как вы можете проверить, что принятые вами решения — правильные?

                                      Я лично — никак. Только общаясь с ребятами поопытнее и поумнее. Для этого и существуют тим-лиды в тиме и архитекторы — что бы подходить и советоваться, что лучше и как лучше сделать.

                                      Что такое «неправильная» архитектура, и как отличить ее от правильной? Гарантирует ли следование вашим «базовым принципам», что «неправильная» архитектура не получится?

                                      Ну, например, если мы уже говорили за книжку мелкомягких и их апликейшн — тогда поясню, что я думаю, было бы плохо. Точно было бы плохо написать Raw SQL запросы прям в контролер екшене, оттуда же отправить event на message-broker и залогировать все, к примеру. И это бы противоречило принципам, описанным в книге.
                                        0
                                        Есть варианты, описаны в ещё одной книжке

                                        Да понятно, что есть, вопрос, во сколько они обойдутся.


                                        Я лично — никак

                                        Ну то есть вам лично эта книжка помогла принять решения, но вы не знаете, правильные ли они?


                                        Ну, например, если мы уже говорили за книжку мелкомягких и их апликейшн

                                        Я понятия не имею, что там за апликейшн.


                                        Точно было бы плохо написать Raw SQL запросы прям в контролер екшене, оттуда же отправить event на message-broker и залогировать все, к примеру.

                                        Почему?


                                        Собственно, у меня в свежем проекте есть AWS Lambda, которая шлет прямой запрос в AWS CloudSearch, отправляет событие в другую лямбду, и все это логирует. Как раз как вы описали. Это плохая архитектура? Почему?


                                        И это бы противоречило принципам, описанным в книге.

                                        Я задал другой вопрос, если вы помните: "Гарантирует ли следование вашим «базовым принципам», что «неправильная» архитектура не получится?"


                                        Впрочем, вопрос, какая же архитектура неправильная, почему, и как ее отличить от правильной, меня волнует больше.

                                          0
                                          Я задал другой вопрос, если вы помните: «Гарантирует ли следование вашим «базовым принципам», что «неправильная» архитектура не получится?»


                                          нет не гарантирует — все индивидуально, я думаю. Мне кажется никакая книга ничего гарантировать не может, просто по причине того, что ее можно не правильно понять, как минимум.

                                          Собственно, у меня в свежем проекте есть AWS Lambda, которая шлет прямой запрос в AWS CloudSearch, отправляет событие в другую лямбду, и все это логирует. Как раз как вы описали. Это плохая архитектура? Почему?

                                          Я говорю не за лямбду, я с этим никогда не работал. Я имел в виду сложный сервис(стандартный asp net) который имеет достаточно много логики, которая в последствии может меняться. Как минимум это будет виолейтить SRP, если написать и логирование, и запросы в бд, и ивенты на меседж брокер в екшене контроллера. Если же говорить о простой логике, я думаю можно это сделать и там. Повторяю ещё раз нету решения, которое бы подходило для всего, нужно думать что, как и где применять.

                                          Я понятия не имею, что там за апликейшн.
                                          я его неоднократно упоминал выше — семплик от майкрософтов, как бороться со сложностью апликейшна, как пишутся микросервисные архитектуры, как их деплоить.

                                          Ну то есть вам лично эта книжка помогла принять решения, но вы не знаете, правильные ли они?

                                          Все зависит от сложности проблемы. Но все же, я думаю, перепроверять никогда не помешает в более опытных коллег.
                                            0
                                            нет не гарантирует

                                            Тогда какой в них смысл?


                                            Я говорю не за лямбду, я с этим никогда не работал

                                            Гм. А как тогда понять, куда можно применять принципы из книжки, а куда нельзя?


                                            Как минимум это будет виолейтить SRP, если написать и логирование, и запросы в бд, и ивенты на меседж брокер в екшене контроллера.

                                            И что? Почему это плохо?


                                            Повторяю ещё раз нету решения, которое бы подходило для всего, нужно думать что, как и где применять.

                                            Тааак… и что является аргументами для этого "думать"? Какие критерии? Как отличить правильное решение от неправильного?


                                            я его неоднократно упоминал выше — семплик от майкрософтов

                                            Вот я и говорю: понятия не имею.


                                            как пишутся микросервисные архитектуры, как их деплоить.

                                            Вы только что написали, что не говорите за лямбду, а теперь пишете про микросервисные архитектуры. Гм...


                                            Все зависит от сложности проблемы.

                                            Ну так я говорю про конкретно те решения, которые вы приняли. Это были сложные проблемы или простые?

                                              0
                                              Тогда какой в них смысл?

                                              Ну тут вы тоже не совсем правы. Ремень безопасности тоже например не гарантирует что вы переживёте аварию. Но это не значит что в нём нет смысла. И на мой взгляд «следование базовым принципам» конечно не гарантирует что мы не получим «неправильную архитектуру», но уменьшает вероятность такого исхода.

                                              П.С. Особенно если человек их применяющий не является экспертом, то следуя им он гораздо меньшей вероятностью получит «плохую архитектуру» чем без них.
                                              П.П.С. Стоит ли «не экспертам» заниматься архитектурой это вопрос отдельный :)
                                                0
                                                Ну тут вы тоже не совсем правы.

                                                Не прав в том, что задаю вопрос?


                                                И на мой взгляд «следование базовым принципам» конечно не гарантирует что мы не получим «неправильную архитектуру», но уменьшает вероятность такого исхода.

                                                Один пункт забыли: разумное следование. Ну да, с этим спорить сложно. Только до этого понимания еще надо дойти, к сожалению.


                                                Особенно если человек их применяющий не является экспертом, то следуя им он гораздо меньшей вероятностью получит «плохую архитектуру» чем без них.

                                                А вот это как раз совершенно не обязательно: следуя этим принципам тоже можно очень легко получить плохую архитектуру. Проблема, как обычно, в балансе.

                                                  +1
                                                  Не прав в том, что задаю вопрос?

                                                  В том что уж совсем зашугали бедного strong junior developer'a :)

                                                  А вот это как раз совершенно не обязательно: следуя этим принципам тоже можно очень легко получить плохую архитектуру.

                                                  Конечно можно. Но точно так же её можно получить если иметь эксперта с многолетним опытом работы и т.д. и т.п. Вопрос в том какой шанс что получится плохая или хорошая архитектура в том или ином случае :)

                                                  И да, голову включать всегда надо и без этого всё равно не обойдёшься. И такие «базовые принципы» всего лишь немного «сокращают путь» и позволятют избежать пары-тройки лишних шишек(из бесчиcленного количества возможных :) ).
                                                    0
                                                    В том что уж совсем зашугали бедного strong junior developer

                                                    Это полезно. В том смысле, что задавать себе вопросы — очень полезно.


                                                    Вопрос в том какой шанс что получится плохая или хорошая архитектура в том или ином случае

                                                    И вот это очень интересный вопрос, да. И мой пойнт, not too subtle at that, состоит в том, что в статье описан случай, который с большей вероятностью приведет к плохой архитектуре, чем к хорошей.

                                                      +1
                                                      Это полезно. В том смысле, что задавать себе вопросы — очень полезно.

                                                      Однозначно. И если честно я бы тоже сказал что молодой человек книжку прочитал, базовые принципы запомнил, но зачем они на самом деле нужны пока ещё не совсем понял. Но это как с огнём: надо один раз обжечься чтобы понять почему с огнём надо вести себя аккуратно.
                                                      И чтобы понять зачем нужны подобные принципы, SOLID, clean code, и куча других вещей надо на мой взгляд сначала на своём собственном опыте ощутить к чему приводит их отсутствие или неправильное использование.

                                                      И мой пойнт, not too subtle at that, состоит в том, что в статье описан случай, который с большей вероятностью приведет к плохой архитектуре, чем к хорошей.

                                                      Ну если кто-то в принципе решит строить свою архитектуру по статье джуниора на хабре, в которой он описывaет своё понимание книжки по архитектуре(да ещё и на мой взгляд достаточно абстрактно написаной), то это 100% ни к чему хорошему не приведёт. Но сама книжка, опять же на мой взгляд, всё-таки не так уж и плоха :)
                                                        0
                                                        Но сама книжка, опять же на мой взгляд, всё-таки не так уж и плоха

                                                        Я честно скажу, я не помню, читал я ее, или нет. Мне нравится Мартиновский Clean Coder, но в первую очередь за не-технические советы. В остальном я разделяю высказанное тут неподалеку мнение: Мартин хорошо задает вопросы, но плохо дает на них ответы.

                                                          +2
                                                          Ну она немного более «техническая» чем «clean coder», но всё ещё достаточно абстрактна и полна хороших вопросов. И я там тоже не всегда был согласен с конкрентыми «ответами». Но если уже читал другие книжки Мартина, то она вполне себе.

                                                          То есть если бы меня попросили её коротко охарактеризовать, то для эксперта она наверна уже бессмыслена и интересна только как беллетристика. Для «одинокого» джуниора немного опасна. А вот каким-нибудь миддлам и начинающим сениорам её вполне себе стоит прочитать.
                                                  0
                                                  П.П.С. Стоит ли «не экспертам» заниматься архитектурой это вопрос отдельный :)

                                                  конечно не стоит, поэтому «не экспертам» такое не доверяют, но что бы стать экспертом, нужно учится, советоваться, спрашивать обсуждать и практиковать, не знаю иных способов.
                                                  0
                                                  И что? Почему это плохо?

                                                  Ну могу кинуть референс на СОЛИД и какие проблемы первая рекомендация может помочь решить, но думаю вы и сами найдете.
                                                  Тааак… и что является аргументами для этого «думать»? Какие критерии? Как отличить правильное решение от неправильного?
                                                  Как я бы то делал? Советовался, писал бы на форумы, думал сам бы — вот как.

                                                  Вот я и говорю: понятия не имею.
                                                  github.com/dotnet-architecture/eShopOnContainers

                                                  Ну так я говорю про конкретно те решения, которые вы приняли. Это были сложные проблемы или простые?

                                                  И такие бывали, и такие
                                                    0
                                                    Ну могу кинуть референс на СОЛИД

                                                    Ну то есть следование SOLID позволяет написать архитектуру, которая хороша, потому что она соответствует SOLID. Так?


                                                    Как я бы то делал? Советовался, писал бы на форумы, думал сам бы — вот как.

                                                    Если вас послушать, получается, что книжка про "чистую архитектуру" не дала вам ни одного (нециклического) критерия того, что же такое хорошая архитектура.


                                                    github.com/dotnet-architecture/eShopOnContainers

                                                    Я и говорю: понятия не имею.


                                                    И такие бывали, и такие

                                                    Давайте возьмем простые. Как вы можете проверить, что принятые вами решения — правильные?

                                                      0
                                                      Один пункт забыли: разумное следование.
                                                      ваше примечание.

                                                      Если вас послушать, получается, что книжка про «чистую архитектуру» не дала вам ни одного (нециклического) критерия того, что же такое хорошая архитектура.

                                                      Потому что архитектура — это не стандарт, я думаю прям абсолютной объективности здесь нельзя ожидать

                                                      Давайте возьмем простые. Как вы можете проверить, что принятые вами решения — правильные?


                                                      Окей, банальный свой проект, REST, решение: инапсулировать доступ к бд, и не писать в екшене контроллера RAW SQL, следуя, как минимум SRP & DIP. Спросил коллег: «стоит ли нагромождать екшн контроллера запросами к бд скюельными», получил ответ — «не стоит». Понял, что вероятность того, что не стоит, достаточно велика по сравнению с тем, что бы писать все в екшне.
                                                        0
                                                        Потому что архитектура — это не стандарт, я думаю прям абсолютной объективности здесь нельзя ожидать

                                                        А я не прошу объективности, я прошу нециклических критериев того, что такое "хорошая архитектура".


                                                        Окей, банальный свой проект, REST, решение: инапсулировать доступ к бд, и не писать в екшене контроллера RAW SQL, следуя, как минимум SRP & DIP.

                                                        Ну то есть ваш критерий правильности архитектуры — "коллеги согласились"?

                                                          0
                                                          А я не прошу объективности, я прошу нециклических критериев того, что такое «хорошая архитектура».

                                                          Как по мне архитектура, которая дает простоту в понимании, в особенности для нового человека, и архитектура которая позволяет более быстро и безболезненно менять логику и поведение.

                                                          Ну то есть ваш критерий правильности архитектуры — «коллеги согласились»?


                                                          Пока да, это мнение других,, более умных и опытных людей, иначе пока не придумал как это сделать быстро. Единственный вариант — свою хорошесть архитектура проявит когда станет вопрос о изменении логики, поведения и т.д.
                                                            0
                                                            Как по мне архитектура, которая дает простоту в понимании, в особенности для нового человека, и архитектура которая позволяет более быстро и безболезненно менять логику и поведение.

                                                            По обоим этим критериям, как ни странно, архитектура с DI и разделением на слои — плохая. Потому что чтобы понять, что делается, нужно просмотреть больше кода, и чтобы изменить одну операцию, нужно изменить больше кода.


                                                            Пока да, это мнение других

                                                            Получается, что книжка для вас в этом оказалась бесполезна.


                                                            (кстати, два абзаца в вашем комментарии противоречат друг другу)

                                                              0
                                                              По обоим этим критериям, как ни странно, архитектура с DI и разделением на слои — плохая. Потому что чтобы понять, что делается, нужно просмотреть больше кода, и чтобы изменить одну операцию, нужно изменить больше кода.


                                                              Изменить, может и больше, но чтобы осознать не повредит это ещё чему-то, не поломает ли это логику чего-то ещё — проще все-таки лейерная архитектура, в силу того, что там стараются выделить независимые компоненты, при изменении которых (в идеальных условиях) ничего сломаться не должно, по крайней мере вероятность меньше.
                                                              И в случае все логики в контроллере(вы спросили чем это плохо), нужно смотреть 100500 строк кода, что бы понять что нужно изменить, вспомнить что вообще здесь происходит. А в лейерной архитектуре — ты строго знаешь какой лейер за что отвечает — сразу идешь туда и изменяешь это там.

                                                              Получается, что книжка для вас в этом оказалась бесполезна.
                                                              Почему же? Ведь перед тем как спросить, ты думаешь сам, читаешь, возвращаешься, опять таки, к принципам книги, и подбираешь какой-то вариант. Книга дает тебе набор принципов и «инструментов» с которых можно выбрать, не читая книги можно было о чем то не знать, либо знать о чем то не очень правильно и т.д.
                                                                0
                                                                Изменить, может и больше, но чтобы осознать не повредит это ещё чему-то, не поломает ли это логику чего-то ещё — проще все-таки лейерная архитектура

                                                                Нет. Потому что если весь код, отвечающий за выполнение сценария, находится в одном месте, то его изменение может повлиять только на этот сценарий и ни на что больше.


                                                                независимые компоненты, при изменении которых (в идеальных условиях) ничего сломаться не должно

                                                                Ну так код, который содержит все, что нужно для сценария, и есть такой независимый компонент.


                                                                А в лейерной архитектуре — ты строго знаешь какой лейер за что отвечает

                                                                Откуда?


                                                                Почему же?

                                                                Потому что она не дала вам критерия, как правильно.

                                                                  0
                                                                  Нет. Потому что если весь код, отвечающий за выполнение сценария, находится в одном месте, то его изменение может повлиять только на этот сценарий и ни на что больше.


                                                                  Я думаю зависит от сложности проекта. Если проект простенький, множества всяких либ и компонентов с сложной логикой там нет — тогда, почему нет?.. Но так или иначе, если например контролер в себе имеет логику написания чистого СКЛ к БД, это виолейшн SRP так точно. Не думаю что это хорошо.

                                                                  Про сложность и независимость: Когда один екшн контролера занимает строк 400, то я думаю, для этого и придумали лейерную архитектуру(тот же самый DDD), что бы изолировать независимые между собою компоненты, что упрощает понимание, потому что конкретный компонент отправки меседжа на какой-то брокер легче понять, нежели искать куски этой логики где-то в 400 строках контроллера, может это только мне упрощает чтение и понимание логики. Если бы я увидел в каком-то сервисе, например, артиклах(представим что там ещё и серч енджайн юзается какой-нить), то если я бы увидел в контролере логику валидейшна инпута, запрос(и билдинг запроса) на серч енджайн, запрос(и билдинг запроса) на бд, логика склеивания это в оутпут, и отправку к примеру куда то ещё на другой сервис — то мне бы было сложно и неудобно с такой структурой. Противопоставлю этому пример: если бы я увидел 3 интерфейса — для серч енджайна, для бд, для отправки на внешний сервис, мне было бы легче и быстрее понять этот код, и что делает этот экшн в контроллере.

                                                                    0
                                                                    Если проект простенький, множества всяких либ и компонентов с сложной логикой там нет — тогда, почему нет?..

                                                                    … то есть мы приходим к тому, что "хорошая архитектура" зависит от проекта? А как понять, какая архитектура хороша для конкретного проекта?


                                                                    Но так или иначе, если например контролер в себе имеет логику написания чистого СКЛ к БД, это виолейшн SRP так точно. Не думаю что это хорошо.

                                                                    Вы это уже говорили. Но почему это "не хорошо"?


                                                                    Противопоставлю этому пример: если бы я увидел 3 интерфейса — для серч енджайна, для бд, для отправки на внешний сервис, мне было бы легче и быстрее понять этот код, и что делает этот экшн в контроллере.

                                                                    Правда?


                                                                    def q(a) =
                                                                      a | q | map (function
                                                                        | Success x -> x | s | option.map f
                                                                        | x -> x
                                                                      ) | map (function
                                                                        | Some x -> x | Content 
                                                                        | None -> HttpError.NotFound
                                                                        | Failure x -> x | HttpError
                                                                    )
                                                                      0
                                                                      то есть мы приходим к тому, что «хорошая архитектура» зависит от проекта? А как понять, какая архитектура хороша для конкретного проекта?
                                                                      Ну если простота сервиса позволяет не делать 100500 абстракций, лейеров и т.д. То нет нужды их делать просто так. Майкрософты в книжке хорошо про это писали. Один сервис они иплементнули просто как CRUD, за'DI'или ормку в контролер, и написали 4 метода CRUD. Потому что сервис простой, и его низкая сложность позволяет так сделать. С другой стороны — они применили DDD принципы при разработке другого -более сложного сервиса. Они могли их применить их и в случае первого, только смысла и денег для этого нет.
                                                                        0
                                                                        Ну если простота сервиса позволяет не делать 100500 абстракций, лейеров и т.д.

                                                                        Она всегда позволяет.

                                                                    0
                                                                    Потому что она не дала вам критерия, как правильно.

                                                                    Цитата автора с книги(architecture chapter): «Software was invented to be 'soft' It was intended to be a way to easily change the behavior of machines. If we'd wanted the behavior of machines to be hard to change, we would have called it hardware
                                                                    To fulfill its purpose, the software must be soft — that is, it must be easy to change»
                                                                      0

                                                                      Ну то есть критерий "как правильно" — это легкость изменения? Все мои аргументы остаются валидными, значит.

                                                                        0
                                                                        Ну то есть критерий «как правильно» — это легкость изменения? Все мои аргументы остаются валидными, значит.


                                                                        Напомните, какие аргументы? Я понмню только кучу вопросов.
                                                                          0

                                                                          Что для легкости изменения не нужна, скажем, архитектура со слоями (и много других "правил" тоже мешают).

                                                                            0
                                                                            Что для легкости изменения не нужна, скажем, архитектура со слоями (и много других «правил» тоже мешают).


                                                                            Ну тогда зачем ребята делали абстракцию, например, на TCP\IP стеке?? Там тоже все на леерах, и она вроде-бы не течет, по крайней мере за столь бедный опыт, не было проблем с этим. Ребята дали абстракцию для работы с сетью (сокет), Никто не пишет логики поиска роута, логики транслирования битов в электрические или радио сигналы. ПОЧЕМУ? Почему сделали абстракцию над тем самым ассемблером, почему вы не пишите все на нем? Раз уж вы считаете, что абстракции текут — откажитесь совсем от них, они не несут, как вы сказали ничего полезного. По вашим словам, и простоты они не добавляют, и легкости изменения не дают.
                                                                              0
                                                                              Ну тогда зачем ребята делали абстракцию, например, на TCP\IP стеке?

                                                                              За этим, я думаю, надо в устанавливающие документы идти. Но что-то мне кажется, что не для легкости изменений, нет.


                                                                              ПОЧЕМУ?

                                                                              Потому что так оказалось удобнее.


                                                                              они не несут, как вы сказали ничего полезного

                                                                              Неа, я этого не говорил.


                                                                              Вот вам, кстати, еще один повод подумать (раз уж вы прошлый пример проигнорировали). Есть типичное такое asp.net WebAPI, смена пароля (хэшами не заморачиваемся), один POST с телом. В ответ от него прилетает "Password should be at least 6 letters long", надо это сообщение поменять на "Password should be at least 6 characters long". Только сообщение, больше ничего, всю логику надо оставить как есть.


                                                                              Вот реализация WebAPI номер 1:


                                                                              public void Post(string oldPassword, string newPassword)
                                                                              {
                                                                                //...
                                                                                if (newPassword.Length < 6)
                                                                                  throw new HttpResponseException(HttpStatusCode.BadRequest, "Password should be at least 6 letters long");
                                                                                //...
                                                                                user.Password = newPassword.
                                                                                user.Save();
                                                                              }

                                                                              Вот номер 2:


                                                                              public void Post(PasswordChangeViewModel model)
                                                                              {
                                                                                _userService.ChangePassword(model.OldPassword, model.NewPassword);
                                                                              }

                                                                              В каком из вариантов вы поменяете сообщение быстрее? Если этот вопрос кажется вам издевательским, то вот вам более интересный: где вообще искать это сообщение во втором случае?

                                                                                0
                                                                                В каком из вариантов вы поменяете сообщение быстрее? Если этот вопрос кажется вам издевательским, то вот вам более интересный: где вообще искать это сообщение во втором случае?

                                                                                Есть для этого разного рода валидаторы, от дефолтных аспнетовских — где можно атрибутами навешать почти все констрейнты — до флюент валидаторов.
                                                                                Но конкретно в этом примере — оставить это в контролере это нормально, потому что далеко не факт, что юзерСервис должен валидацией заниматься.

                                                                                За этим, я думаю, надо в устанавливающие документы идти. Но что-то мне кажется, что не для легкости изменений, нет.
                                                                                Не только за этим, но за этим в ТОМ ЧИСЛЕ. Потому что, с такисм пожзодом легко свичнуться например с UDP -> TCP, и при этом логика IP & LINK лееров будет не затронута, их не надо апдейтить, редеплоить и т.п. ВОТ одна из причин почему, я думаю. Плюс к тому, для борьбы со сложностью, потому что каждый леер представляет довольно сложно реализующуюся логику с разного рода алгоритмами и т.д.
                                                                                  0
                                                                                  Есть для этого разного рода валидаторы, от дефолтных аспнетовских — где можно атрибутами навешать почти все констрейнты — до флюент валидаторов.

                                                                                  Вот в этом и был мой вопрос: передо мной есть такой код, где мне искать это сообщение?


                                                                                  public void Post(PasswordChangeViewModel model)
                                                                                  {
                                                                                    _userService.ChangePassword(model.OldPassword, model.NewPassword);
                                                                                  }

                                                                                  Но конкретно в этом примере — оставить это в контролере это нормально, потому что далеко не факт, что юзерСервис должен валидацией заниматься.

                                                                                  Гм. А я-то думал, проверка бизнес-ограничений в бизнес-слое быть обязана… И как же на самом деле надо делать?


                                                                                  Плюс к тому, для борьбы со сложностью

                                                                                  И это первый раз, когда вы вообще упоминаете борьбу со сложностью как критерий качества.

                                                                                    0
                                                                                    Гм. А я-то думал, проверка бизнес-ограничений в бизнес-слое быть обязана… И как же на самом деле надо делать?
                                                                                    Может быть я не прав, но это не бизнес правило — это валидация инпута.

                                                                                    И это первый раз, когда вы вообще упоминаете борьбу со сложностью как критерий качества.
                                                                                    Так или иначе, я его упомянул.
                                                                                      0
                                                                                      Может быть я не прав, но это не бизнес правило — это валидация инпута.

                                                                                      Вы не правы. Длина пароля — это бизнес-правило.


                                                                                      (я, собственно, не понимаю, что за "валидация инпута", которая не вызвана бизнес-правилами)

                                                                                        0
                                                                                        Вы не правы. Длина пароля — это бизнес-правило.


                                                                                        Ну тогда, этот инпут должен конвертироваться в доменную модель, которая, в свою очередь должна валидить. никак не можно считать сходной моделью конроллера — бизнес моделью — опять таки виолейшн SRP.

                                                                                        Даже в случае с юзер сервисом, должен быть валидатор, я думаю, как отдельный сервис, и в нем уже искать валидацию. либо же не усложнять себе жизнь и прописать все в контроллере. Если это позволяет сложность.

                                                                                        (я, собственно, не понимаю, что за «валидация инпута», которая не вызвана бизнес-правилами)


                                                                                        Насколько мне известно, валидация инпута, и бизнесс-констрейнты — это разные вещи.
                                                                                          0
                                                                                          Ну тогда, этот инпут должен конвертироваться в доменную модель,

                                                                                          Где-то, наверное, конвертируется. В приведенном примере (userService.ChangePassword(model.OldPassword, model.NewPassword)) модель, связанная с представлением, не покидает presentation layer.


                                                                                          никак не можно считать сходной моделью конроллера — бизнес моделью — опять таки виолейшн SRP.

                                                                                          Я не понимаю, что вы хотели сказать.


                                                                                          Даже в случае с юзер сервисом, должен быть валидатор, я думаю, как отдельный сервис, и в нем уже искать валидацию

                                                                                          Попробуйте просто перечислить, сколько уже мест, где искать валидацию, вы назвали, и сколько еще потенциально есть. Знаете, просто в списочек.


                                                                                          либо же не усложнять себе жизнь и прописать все в контроллере. Если это позволяет сложность.

                                                                                          Что значит "позволяет сложность"? Весь пример — перед вами; сложность позволяет или нет?


                                                                                          Насколько мне известно, валидация инпута, и бизнесс-констрейнты — это разные вещи.

                                                                                          Это разные вещи, потому что одно — следствие другого. Это никак не отменяет того, что валидация инпута, не вызванная бизнес-правилами — редкая и специфическая вещь (и обычно ее все равно можно проследить до бизнес-требования).

                                                                                            0
                                                                                            никак не можно считать сходной моделью конроллера — бизнес моделью — опять таки виолейшн SRP.
                                                                                            Я не понимаю, что вы хотели сказать.


                                                                                            Входная модель контролера — не имеет ничего общего с Доменом

                                                                                            Попробуйте просто перечислить, сколько уже мест, где искать валидацию, вы назвали, и сколько еще потенциально есть. Знаете, просто в списочек.


                                                                                            Если вы — новый человек в проекте — то нужно, наверное, спросить в ответственного человека — какая архитектура, и какой компонент ответственный за валидацию — и искать её там. Нету точного определения, где должна быть валидация, как и вообще нету конкретных стандартов правильной архитектуры, ну или киньте мне какой-то аналог RFC, где бы четко было прописано «как надо». Нужно прежде всего думать. А книга это набор принципов и инструментов, которые можно использовать — можно не использовать, никто же не запрещал. Только вот в нужном месте использование их — уменьшит вероятность нагавнить своим «велосипедом»
                                                                                              0
                                                                                              Входная модель контролера — не имеет ничего общего с Доменом

                                                                                              Не обязана иметь. Ну да, в примере так и есть. И что?


                                                                                              Если вы — новый человек в проекте — то нужно, наверное, спросить в ответственного человека — какая архитектура, и какой компонент ответственный за валидацию — и искать её там.

                                                                                              Ну то есть что читай книжки, что не читай, что следуй паттернам, что не следуй — все равно надо идти и спрашивать. В чем тогда смысл?


                                                                                              А книга это набор принципов и инструментов, которые можно использовать

                                                                                              А теперь давайте это сравним с вашим же утверждением из поста:


                                                                                              И вот как строить эту архитектуру, как избавится от головной боли при маленьком изменении требований от PM’а, или от стейкхолдера: об этом и поведает книга
                                                                                                0
                                                                                                Ну то есть что читай книжки, что не читай, что следуй паттернам, что не следуй — все равно надо идти и спрашивать. В чем тогда смысл?
                                                                                                в том, что если скажут, там все по DDD, ты сразу поймешь где они должны бы быть.

                                                                                                А теперь давайте это сравним с вашим же утверждением из поста:

                                                                                                И где тут противоречие? Следуя принципам, разумным, естевственно, вероятность налажать будет меньше, я думаю.
                                                                                                  0
                                                                                                  в том, что если скажут, там все по DDD, ты сразу поймешь где они должны бы быть.

                                                                                                  И где же? Вот представьте себе, что я вам сказал, что в этом примере все по DDD. Дальше что?


                                                                                                  Следуя принципам, разумным, естевственно, вероятность налажать будет меньше, я думаю.

                                                                                                  Пока что вам не удалось никак эту мысль подтвердить.

                                                                                                    0
                                                                                                    И где же? Вот представьте себе, что я вам сказал, что в этом примере все по DDD. Дальше что?


                                                                                                    так как имеем дело с инпутом, скорее всего должно быть в апликейшн лейере. так же, если это уже относится к Домену, валидация и некоторые констрейны могут быть и в домене, в какой-то ентите к примеру. Так или иначе, если вся валидация там или там, то она на весь сервис там будет. И не нужно будет искать каждый раз в разном месте.

                                                                                                    Пока что вам не удалось никак эту мысль подтвердить.

                                                                                                    как и вам — вашу. Как по мне, накидать все в екшн контроллера и сказать «что в этом плохого» — так себе идея. по крайней мере не видел такого ни в одном коммерческом проекте, и ни одного совета ни от одного дева, кроме вас, делать так.
                                                                                                      0
                                                                                                      Так или иначе, если вся валидация там или там,

                                                                                                      Так как же узнать, в каком из двух (на самом деле — больше) "там" валидация, ни у кого не спрашивая? Вы только что говорили, что если сказано, что "по DDD", сразу понятно, где.


                                                                                                      И не нужно будет искать каждый раз в разном месте.

                                                                                                      Нужно, нужно. Даже у вас нужно как минимум два места обойти. А теперь я вам добавлю веселья: если этот же сценарий вызывается из браузера, проверка должна делаться на клиентской стороне (отзывчивость, вот это всё).


                                                                                                      как и вам — вашу

                                                                                                      Мне кажется, вы пока даже не понимаете мою мысль, о каком уж подтверждении тут говорить.

                                                                                                        0
                                                                                                        Нужно, нужно. Даже у вас нужно как минимум два места обойти. А теперь я вам добавлю веселья: если этот же сценарий вызывается из браузера, проверка должна делаться на клиентской стороне (отзывчивость, вот это всё).

                                                                                                        Не нужно, если ты уже раз видел где валидация на проекте.

                                                                                                        Так как же узнать, в каком из двух (на самом деле — больше) «там» валидация, ни у кого не спрашивая? Вы только что говорили, что если сказано, что «по DDD», сразу понятно, где.

                                                                                                        Окей перефразирую — ты будешь знать где валидации точно не может быть. И я ещё раз повторяю, в вашем примере не вижу ничего плохого, что бы держать валидацию в контрллере. теперь представьте, там моделька на 15 пропертей, и в каждой делать иф, потом ещё логику в контроллер запихнуть — это уже посложнее будет выглядеть, и разобраться в этом посложнее будет. Ну лично мне проще перейди в какую-то папочку «validation», и разобраться там с 20 строками, нежели бегать по всему екшене на 400 строк.

                                                                                                        Мне кажется, вы пока даже не понимаете мою мысль, о каком уж подтверждении тут говорить.

                                                                                                        Ну пока, конкретные мысли которые вы пытались донести, кроме 100500 вопросов лично мне:
                                                                                                        — абстракции текут, в прочем, разработчики ОС, например, разработчики TCP\IP доказали, что не всегда они текут.
                                                                                                        — что на мое «напихать всю логику в контроллере» — вы ответили, «а что в этом плохого». И виолейшн обычного SOLID принципа — это в порядке вещей, и тоже нормально. С чем я тоже, не согласен. В большинстве случаев, это может привести к проблемам.
                                                                                                          0
                                                                                                          Не нужно, если ты уже раз видел где валидация на проекте.

                                                                                                          Мы говорим о человеке, который первый раз пришел на проект, и еще не видел. Если уже видел, то понятно, что вопросов нет.


                                                                                                          Окей перефразирую — ты будешь знать где валидации точно не может быть.

                                                                                                          И где же?


                                                                                                          И я ещё раз повторяю, в вашем примере не вижу ничего плохого, что бы держать валидацию в контрллере

                                                                                                          Это автоматически означает, что валидация не в одном месте.


                                                                                                          разработчик ОС, например, разработчики TCP\IP доказали, что не всегда они текут.

                                                                                                          Нет, не доказали. Чего далеко ходить, вы про проблемы с HttpClient в .net не слышали?


                                                                                                          что на мое «напихать всю логику в контроллере» — вы ответили, «а что в этом плохого».

                                                                                                          Это тоже был вопрос, если что.


                                                                                                          С чем я тоже, не согласен.

                                                                                                          То, что вы не согласны, понятно. Почему не согласны — тоже понятно, в книжке написано, что это плохо. Это всё?


                                                                                                          В большинстве случаев, это может привести к проблемам.

                                                                                                          Любой код может привести к проблемам. Вопрос в том, какой код приведет к проблемам с меньшей вероятностью, и тут ваши тезисы меня пока никак не убеждают.

                                                                                                            0
                                                                                                            абстракции текут, в прочем, разработчики ОС, например, разработчики TCP\IP доказали, что не всегда они текут.

                                                                                                            Кстати, забавно. Джоэл Спольски, который озвучил "закон текущих абстракций" ("All non-trivial abstractions, to some degree, are leaky"), показывает его на примере… TCP/IP.

                                                                                                              0
                                                                                                              Кстати, забавно. Джоэл Спольски, который озвучил «закон текущих абстракций» («All non-trivial abstractions, to some degree, are leak
                                                                                                              Мельком пробежался по статейке, что-то в этом есть. Я не буду как то это комментировать, в следствие того, что человек имеет побольше опыта, я сейчас говорю о ТСП, не как о гарантии доставки, а о том, что они вынесли логику, независимую одну от другой отдельно. И это позволяет так просто свичнуться к примеру с TCP на UPD, и не нужно ничего делать с двумя нижними лейерами.
                                                                                                                0
                                                                                                                они вынесли логику, независимую одну от другой отдельно

                                                                                                                Это никак не отменяет закона текущих абстракций. И конкретно абстрация TCP/IP — течет.

                                                                                                                  0
                                                                                                                  Окей, дайте точное определени «текущей» абстракции.

                                                                                                                  И что же вы скажете в этом случае про ОС. У них очень даже неплохо получилось абстрагироваться от железа. Насколько все проще становиться, когда тебя не заботит как все устроенно там, под коробкой, ты просто используешь интерфейс. Это экономит время, ресурсы.
                                                                                                                    0
                                                                                                                    Окей, дайте точное определени «текущей» абстракции.

                                                                                                                    Это написано в статье, на которую я дал ссылку, и по которой вы "пробежались".


                                                                                                                    This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from.

                                                                                                                    Проще говоря, текущая абстракция — это когда то, что за абстракцией все равно влияет на вас, как на пользователя.


                                                                                                                    И что же вы скажете в этом случае про ОС.

                                                                                                                    То же самое. Вы можете не заботиться, как оно там устроено, а потом вам надо гарантировать D из ACID, и все, добро пожаловать в маленький ад.


                                                                                                                    Да что там D-из-ACID, банальное различие между SSD и HDD может привести к тому, что один и тот же код выполняется быстро или медленно (и, наоборот, если мы хотим, чтобы код выполнялся быстро, нам надо прилагать дополнительные усилия). Абстракция? Да. Протекла? Да.

                                                                                                                      0
                                                                                                                      Окей, но плюсы то все ровно есть, и сложность, и изменение, не нравиться SSD — юзни HDD, а вызывающий код трогать не надо.
                                                                                                                      Проще говоря, текущая абстракция — это когда то, что за абстракцией все равно влияет на вас, как на пользователя


                                                                                                                      Ну окей, но от лейера IP & LINK абстрагороваться то получилось. И работает, ещё ни разу не слышал что бы один из них делал что-то некорректно. И их может юзать как TCP так и UDP, и их не заботит как он устроен.
                                                                                                                        0
                                                                                                                        Окей, но плюсы то все ровно есть

                                                                                                                        Плюсы — есть.


                                                                                                                        не нравиться SSD — юзни HDD, а вызывающий код трогать не надо.

                                                                                                                        … вот только он взял и просел по скорости на порядок, а так да, трогать ничего не надо.


                                                                                                                        Ну окей, но от лейера IP & LINK абстрагороваться то получилось.

                                                                                                                        Ключевое — как-то.

                                                                                                                          0
                                                                                                                          … вот только он взял и просел по скорости на порядок, а так да, трогать ничего не надо.
                                                                                                                          ну так поменять будет проще, из-за абстракции, ибо не тонешь в 100500 строках асма.

                                                                                                                          Ключевое — как-то.
                                                                                                                          Вы в этом участвовали? что точно знаете, что как-то? Так или иначе — получилось. Поэтому НЕ ВСЕ — текут. Я думаю можно сделать максимально не-текущие абстракции, вопрос в релевантности и денежных запасах.
                                                                                                                            0
                                                                                                                            ну так поменять будет проще, из-за абстракции, ибо не тонешь в 100500 строках асма.

                                                                                                                            Проще, чем в каком случае?


                                                                                                                            Вы в этом участвовали?

                                                                                                                            Я этим пользуюсь. И при отладке сетей дома прыгать между уровнями приходится.


                                                                                                                            Поэтому НЕ ВСЕ — текут.

                                                                                                                            Цитата выше, спорьте с автором. Я не видел ни одной абстракции, которая бы не текла рано или поздно.

                                                                                                                              0
                                                                                                                              Проще, чем в каком случае?
                                                                                                                              чем если все запихнуть в один метод, в один компонент на 100000000 строк.
                                                                                                                              И при отладке сетей дома прыгать между уровнями приходится.
                                                                                                                              между какими уровнями?

                                                                                                                              Цитата выше, спорьте с автором. Я не видел ни одной абстракции, которая бы не текла рано или поздно.
                                                                                                                              Пример IP лейер стэка — где здесь утечка? Может это и так, я не спорю, просто я пока её не вижу, и хотелось бы видеть
                                                                                                                                0
                                                                                                                                чем если все запихнуть в один метод, в один компонент на 100000000 строк.

                                                                                                                                А откуда вы взяли эту альтернативу? Я ее не озвучивал.


                                                                                                                                между какими уровнями?

                                                                                                                                Как минимум — application и transport. И я хорошо знаю, что нельзя просто взять и заменить tcp на udp — можно и связность потерять.


                                                                                                                                Пример IP лейер стэка — где здесь утечка?

                                                                                                                                В статье, которую вы проглядели.

                                                                                                                                  0
                                                                                                                                  А откуда вы взяли эту альтернативу? Я ее не озвучивал.
                                                                                                                                  но вы сказали «что плохого в том», когда я написал вариант засунуть в контролер логику серч енджайна, бд, логирования и конвертацию моделей.

                                                                                                                                  В статье, которую вы проглядели.
                                                                                                                                  там только за TCP. С этим, пожалуй пока соглашусь.

                                                                                                                                  Как минимум — application и transport. И я хорошо знаю, что нельзя просто взять и заменить tcp на udp — можно и связность потерять.
                                                                                                                                  ну да, апликейшн лейер будет зависеть от транспортного, потому что две разные имплементации транспортного в корне разные. Но вы глядите глубже, вам же не приходилось залезать в LINK & IP лейер?
                                                                                                                                    0
                                                                                                                                    но вы сказали «что плохого в том», когда я написал вариант засунуть в контролер логику серч енджайна, бд, логирования и конвертацию моделей.

                                                                                                                                    Я спросил, что плохого.


                                                                                                                                    ну да, апликейшн лейер будет зависеть от транспортного, потому что две разные имплементации транспортного в корне разные.

                                                                                                                                    Подождите, но как же, как же абстракция?


                                                                                                                                    Но вы глядите глубже, вам же не приходилось залезать в LINK & IP лейер?

                                                                                                                                    Лично мне не приходилось, я вообще сетями не занимаюсь.

                                                                                                                                      0
                                                                                                                                      Подождите, но как же, как же абстракция?
                                                                                                                                      Простите, а где Я говорил что ВСЕ абстракции идеальные, и работают? Я говорю что НЕ ВСЕ плохие.
                                                                                                                                      Я спросил, что плохого.
                                                                                                                                      Если спросили — значит не знаете, или как?
                                                                                                                                        0
                                                                                                                                        Простите, а где Я говорил что ВСЕ абстракции идеальные, и работают? Я говорю что НЕ ВСЕ плохие.

                                                                                                                                        Я тоже не говорил, что все — плохие. Я говорил, что все — текут. Это не отменяет того, что даже текущие абстракции могут быть полезны, просто надо каждый (каждый!) раз помнить, что та абстрация, на которую ты сейчас встал, может потечь и потопить тебя.


                                                                                                                                        Если спросили — значит не знаете, или как?

                                                                                                                                        Значит, не знаю, почему вы утвержаете, что это плохо.

                                                                                                                                          0
                                                                                                                                          Значит, не знаю, почему вы утверждаете, что это плохо.
                                                                                                                                          в таком случае я объяснил, почему, по моему, это плохо. Да и не только по моему.

                                                                                                                                          Я говорил, что все — текут. Это не отменяет того, что даже текущие абстракции могут быть полезны, просто надо каждый (каждый!) раз помнить, что та абстракция, на которую ты сейчас встал, может потечь и потопить тебя.
                                                                                                                                          Опять таки, пока что, не вижу утечки у IP & LINK лейера, и ОС. Даже в примере с SSD & HDD, разве ОС гарантирует скорость. Она гарантирует, что если система рабочая, она запишет и считает данные
                                                                                                                                            0
                                                                                                                                            в таком случае я объяснил, почему, по моему, это плохо.

                                                                                                                                            Объяснить — объяснили. Но не убедили.


                                                                                                                                            Она гарантирует, что если система рабочая, она запишет и считает данные

                                                                                                                                            … и даже этого она не гарантирует.


                                                                                                                                            А главное, какая мне разница, что она гарантирует? Мне важно, что я не могу просто сделать вид "это абстракция, что за ней — мне не важно", я должен помнить детали конкретных реализаций. Что хуже, иногда абстрация построена так, что я не могу выяснить, какая там реализация (что, в общем-то, еще хуже).

                                                                                                                                              0
                                                                                                                                              А главное, какая мне разница, что она гарантирует? Мне важно, что я не могу просто сделать вид «это абстракция, что за ней — мне не важно», я должен помнить детали конкретных реализаций. Что хуже, иногда абстрация построена так, что я не могу выяснить, какая там реализация (что, в общем-то, еще хуже).


                                                                                                                                              Так а кто сказал, вообще не знать о деталях реализации? Вы скорее всего будете знать, как в общем что-то устроено, описывая очередную имплементацию. Только вот работать с этим проще, при росте проекта, и проще заменить на что-то другое при этом.

                                                                                                                                              … и даже этого она не гарантирует.
                                                                                                                                              Ну почему же? Так, как и с TCP, есть условия, при которых есть гарантии. Так или иначе, имплементация не дает тоже никаких гарантий. Единственное, что дает гарантии в этом мире — это то, что мы все умрем. Если вы хотите гарантий — вам не к абстракциям.
                                                                                                                                                0
                                                                                                                                                Так а кто сказал, вообще не знать о деталях реализации?

                                                                                                                                                Говорят, что information hiding — одна из задач абстракции. Нет?


                                                                                                                                                Ну почему же?

                                                                                                                                                По опыту.


                                                                                                                                                Так, как и с TCP, есть условия, при которых есть гарантии.

                                                                                                                                                Угу. Вот возьмем .net (полный, на винде):


                                                                                                                                                FileStream fs;
                                                                                                                                                //...
                                                                                                                                                fs.Write(someBytes);

                                                                                                                                                В какой момент гарантированно произойдет физическая запись этих байтиков на носитель, и какие условия нужны для выполнения этой гарантии?

                                                                                                                                                  0
                                                                                                                                                  Говорят, что information hiding — одна из задач абстракции. Нет?
                                                                                                                                                  но кто сказал, что это идеально возможно во всех случаях. Тут скорее важно стремление к этому. есть много вообще полезных рекомендаций в жизни, но кто сказал, что их возможно постоянно и на 100% додерживаться?

                                                                                                                                                  В какой момент гарантированно произойдет физическая запись этих байтиков на носитель, и какие условия нужны для выполнения этой гарантии?
                                                                                                                                                  Я точно сказать не могу, я же это не писал. Я думаю, что при том, если все системы пк будут в норме. Конечно есть возможность бага, но она исключительно мала, и легче фиксится, благодаря абстракциям,
                                                                                                                                                    0
                                                                                                                                                    но кто сказал, что это идеально возможно во всех случаях. Тут скорее важно стремление к этому.

                                                                                                                                                    Вот это и ответ на (ваш же) вопрос "кто сказал, вообще не знать о деталях реализации?". Вы сказали. Потому что вы говорите, что важно стремиться к тому, чтобы не знать о деталях реализации. Следовательно, когда я получу абстракцию, написанную по этим правилам, у меня будет минимум (в пределе — ноль) информации о реализации. А это то, что меня не всегда устраивает.


                                                                                                                                                    Я точно сказать не могу, я же это не писал.

                                                                                                                                                    Подождите, один из смыслов абстракции ровно в том, чтобы вы могли ей пользоваться, хотя не вы ее писали. Или нет?


                                                                                                                                                    Я думаю, что при том, если все системы пк будут в норме.

                                                                                                                                                    Это ответ на вопрос "какие условия", но не на вопрос "когда".


                                                                                                                                                    И да, этот набор условий непроверяем. Я, как пользователь этой абстракции, как тот, кто пишет этот код, не имею никакой возможности проверить, что эти условия выполнены, и, как следствие, что мои данные успешно записаны.

                                                                                                                                                      0
                                                                                                                                                      Вот это и ответ на (ваш же) вопрос «кто сказал, вообще не знать о деталях реализации?». Вы сказали. Потому что вы говорите, что важно стремиться к тому, чтобы не знать о деталях реализации. Следовательно, когда я получу абстракцию, написанную по этим правилам, у меня будет минимум (в пределе — ноль) информации о реализации. А это то, что меня не всегда устраивает.
                                                                                                                                                      Ну если не устраивает — так узнайте немного больше. Если это важно в ваших реквайрментах. Может быть такое, что это знать не обязательно. Так или иначе, простоту и легкость в изменении это не отменяет
                                                                                                                                                        0
                                                                                                                                                        Так или иначе, простоту и легкость в изменении это не отменяет

                                                                                                                                                        Отменяет, в том-то и дело. Потому что вы поменяете то, что раньше люди узнали сквозь вашу абстракцию.


                                                                                                                                                        Простота и легкость изменения есть только тогда, когда у вас есть непроницаемый барьер (который и создает абстракция), который говорит, кому, что и как вы должны, и ничего больше. Все за пределами этого "должны" вы вольны менять. Если ваша абстракция протекла, и люди узнали больше, чем это "должны", вы уже не можете это так просто поменять.


                                                                                                                                                        Аналогично и со стороны пользователя: вся видимая простота абстракции сохраняется ровно до того момента, пока мне не нужна конкретная специфика поведения, этой абстракцией не описанного, и дальше абстракция начинает мне активно мешать.

                                                                                                                                                          0
                                                                                                                                                          Отменяет, в том-то и дело. Потому что вы поменяете то, что раньше люди узнали сквозь вашу абстракцию.
                                                                                                                                                          если действительно важно так знать, что-то об имплементации — об этих деталях можно оповестить людей. Если абстракции не делать, это никак не улучшит ситуацию. Все равно придется людей оповестить, что теперь то не юзайте, юзайте это.

                                                                                                                                                          Аналогично и со стороны пользователя: вся видимая простота абстракции сохраняется ровно до того момента, пока мне не нужна конкретная специфика поведения
                                                                                                                                                          Ну пока она не нужна — это работает. Если становиться нужна, ну значит такая сложилась ситуация, подставить другую имплементацию под интерфейс — все равно легче, нежели лазить и барахтаться в имплементации.

                                                                                                                                                          Отменяет, в том-то и дело. Потому что вы поменяете то, что раньше люди узнали сквозь вашу абстракцию.
                                                                                                                                                          По поводу этого — можно пожалуйста пример, когда у вас такая ситуация возникала.
                                                                                                                                                            0
                                                                                                                                                            если действительно важно так знать, что-то об имплементации — об этих деталях можно оповестить людей. Если абстракции не делать, это никак не улучшит ситуацию.

                                                                                                                                                            Зато не надо тратить ресурсы на абстракцию, это уже хорошо.


                                                                                                                                                            Ну пока она не нужна — это работает.

                                                                                                                                                            А дальше вопрос отношения числа случаев.


                                                                                                                                                            Если становиться нужна, ну значит такая сложилась ситуация, подставить другую имплементацию под интерфейс

                                                                                                                                                            Вот только я не могу "подставить другую имплементацию под интерфейс", потому что я потребитель, мне все имплементации передают.


                                                                                                                                                            По поводу этого — можно пожалуйста пример, когда у вас такая ситуация возникала.

                                                                                                                                                            Как-то раз надо было нам запустить процесс парсинга asp.net-страницы внутри IIS. Подняли IIS-овский пайплайн, сделали фейковый запрос, запихнули — падает. Внутри в одном месте они не учли, что запросы бывают фейковые. Ну что, мы написали рядом костыль, котороый это место подменяет, чтобы работало правильно. А потом они в минорной версии поняли, что у них была ошибка, и починили ее — а наш костыль немедленно упал.

                                                                                                                                                              0
                                                                                                                                                              Зато не надо тратить ресурсы на абстракцию, это уже хорошо.
                                                                                                                                                              но фиксить и менять имплементацию сырую — тоже может быть дороже, кроме того, ты не там много потратишь на абстракцию. В случае Артиклов 5 сек на создание интерфейса, 20 — на написание деклараций.

                                                                                                                                                              Вот только я не могу «подставить другую имплементацию под интерфейс», потому что я потребитель, мне все имплементации передают.
                                                                                                                                                              не могу понять почему. Простой пример, в DI в аспнете, когда сервис регистрируешщь, меняешь одну иплементацию на другую, при этом все сервисы, которые юзали ту имплементацию. не нуждаются в рефакторинге, фиксинге и т.д. Даже при билде, они билдится не будут.

                                                                                                                                                              Баг в абстракции — не проблема абстракции, а проблема разработчиков — это не делает её — плохой. Я просто не до конца понял. что за фейковые страницы, что там и как надо было парсить.
                                                                                                                                                                0
                                                                                                                                                                но фиксить и менять имплементацию сырую — тоже может быть дороже

                                                                                                                                                                Нет, не может. Это одни и те же изменения.


                                                                                                                                                                кроме того, ты не там много потратишь на абстракцию

                                                                                                                                                                Вам это неизвестно.


                                                                                                                                                                В случае Артиклов 5 сек на создание интерфейса,

                                                                                                                                                                Вы за пять секунд проектируете интерфейс? Восхищаюсь вами. Я над одним названием метода дольше думаю.


                                                                                                                                                                не могу понять почему.

                                                                                                                                                                Потому что IoC и DI. Я, как потребитель сервиса, не определяю, какую реализацию сервиса мне передают, я должен работать с той, которую передали.


                                                                                                                                                                Простой пример, в DI в аспнете, когда сервис регистрируешщь, меняешь одну иплементацию на другую

                                                                                                                                                                Вы забываете про маленький нюанс: не все "сервисы регистрируете" вы. Что вам передали — с тем и работайте, инфраструктура вам не подконтрольна.


                                                                                                                                                                Баг в абстракции — не проблема абстракции, а проблема разработчиков — это не делает её — плохой.

                                                                                                                                                                Баг не в абстракции, а в реализации. Я не понимаю, зачем просить пример, если любой пример можно отвергнуть с теми же аргументами.

                                                                                                                                                                  0
                                                                                                                                                                  Вы за пять секунд проектируете интерфейс? Восхищаюсь вами. Я над одним названием метода дольше думаю.
                                                                                                                                                                  Я за написание, проектировать вы столько же будете и имплементацию(прототипы)

                                                                                                                                                                  Потому что IoC и DI. Я, как потребитель сервиса, не определяю, какую реализацию сервиса мне передают, я должен работать с той, которую передали
                                                                                                                                                                  Но и без абстракции, вы будете потребителем, и будете работать с теми методами, которые вам представляют.

                                                                                                                                                                  Вы забываете про маленький нюанс: не все «сервисы регистрируете» вы. Что вам передали — с тем и работайте, инфраструктура вам не подконтрольна.
                                                                                                                                                                  та же проблема с имплементациями, они в этом ничем не лучше, а вот для людей, которые «передают», это упрощает жизнь.

                                                                                                                                                                  Баг не в абстракции, а в реализации. Я не понимаю, зачем просить пример, если любой пример можно отвергнуть с теми же аргументами.
                                                                                                                                                                  То есть, если вы некорректно напишите mergesort — то проблема в алгоритме, а не в вас?

                                                                                                                                                                  Нет, не может. Это одни и те же изменения.

                                                                                                                                                                  Да, изменения те же, только чтобы поменять имя переменной в имплементации к примеру — вам не нужно будет ребилдить, и каким-то образом афектить «потребителя» абстракции — а при имплементации — придется.
                                                                                                                                                                    0
                                                                                                                                                                    проектировать вы столько же будете и имплементацию(прототипы)

                                                                                                                                                                    Неа. Если имплементация используется "по месту", она не является долгосрочным контрактом, поэтому нет необходимости ее проектировать как публичную.


                                                                                                                                                                    Но и без абстракции, вы будете потребителем, и будете работать с теми методами, которые вам представляют.

                                                                                                                                                                    Вот только я, например, смогу выбирать, какая реализация мне нужна.


                                                                                                                                                                    а вот для людей, которые «передают», это упрощает жизнь.

                                                                                                                                                                    Неа.


                                                                                                                                                                    То есть, если вы некорректно напишите mergesort — то проблема в алгоритме, а не в вас?

                                                                                                                                                                    То проблема в имплементации.


                                                                                                                                                                    Я смотрю, вы любите некорректные аналогии.


                                                                                                                                                                    Да, изменения те же, только чтобы поменять имя переменной в имплементации к примеру — вам не нужно будет ребилдить, и каким-то образом афектить «потребителя» абстракции — а при имплементации — придется.

                                                                                                                                                                    Если имплементация сырая, то потребитель абстракции все равно будет поаффекчен.

                                                                                                                                                                      0
                                                                                                                                                                      Неа. Если имплементация используется «по месту», она не является долгосрочным контрактом, поэтому нет необходимости ее проектировать как публичную.
                                                                                                                                                                      Я не за это. Ваша имплементация будет содержать ендпоинты, которые будут выполнять какую-то логику — так вот теже ендпоинты на интерфейс переложить, вот что я имел в виду — это не много времени. Так как в начале разработки, скорее всего, вы часто будете менять ендопоинты, но позже, когда разработка подойдет к финишу, будет просто стабильный интерфейс(стабильнее, чем имплементация)
                                                                                                                                                                      Вот только я, например, смогу выбирать, какая реализация мне нужна.
                                                                                                                                                                      ну если вы разработчик — можете, только вот если вы разработчик абстракции с имплементацией — то что мешает поменять имплементацию так же, как и в случае чистой имплементации?

                                                                                                                                                                      Неа.
                                                                                                                                                                      Да, ибо абстракция — упрощает, изолирует логики между собой, это упрощает задачу в изменении. Для чего же по вашему придумали паттерны, к примеру? Потому что были проблемы, вот с такими «грубыми» имплементациями. Все паттерны строятся через абстракцию.
                                                                                                                                                                      То проблема в имплементации.
                                                                                                                                                                      Ну вот, но вы же не скажете, что сам алгоритм плох при этом? Или скажете? Именно это вы и сказали, говоря про то, как вы парсили через IIS. То, что майкрософты не углядели баг — не делает саму абстракцию плохой.

                                                                                                                                                                      Я смотрю, вы любите некорректные аналогии.
                                                                                                                                                                      А чем плоха та аналогия?

                                                                                                                                                                      Если имплементация сырая, то потребитель абстракции все равно будет поаффекчен.
                                                                                                                                                                      Каким образом? Сразу пример. Имею либу(что бы сразу отпали вопросы, либа — потому, что логика будет использоваться повторно), и аспнет. В аспнете интерфейс, имплементация в либе. Есть один метод в интерфейсе, описанный. Билджу все — все окей. теперь, к примеру, нужно кусочек логики переписать в либе. Переписываю — билджу, аспнет не билдится. Почему? потому, что зависимости нету на либу. Либа зависит от абстракции. Все по Депенденси рулу. В случае вырой имплементации, аспнет бы тоже ребилдился.

                                                                                                                                                                        0
                                                                                                                                                                        Ваша имплементация будет содержать ендпоинты, которые будут выполнять какую-то логику — так вот теже ендпоинты на интерфейс переложить, вот что я имел в виду — это не много времени.

                                                                                                                                                                        Если это делать после разработки — то да, немного. Но тогда все время разработки я буду зависеть от имплементации.


                                                                                                                                                                        ну если вы разработчик — можете, только вот если вы разработчик абстракции с имплементацией — то что мешает поменять имплементацию так же, как и в случае чистой имплементации?

                                                                                                                                                                        Я не понимаю, что вы спрашиваете.


                                                                                                                                                                        Да, ибо абстракция — упрощает, изолирует логики между собой, это упрощает задачу в изменении.

                                                                                                                                                                        Это вы так говорите. А в реальности это далеко не всегда так, и это всегда приносит с собой дополнительные проблемы.


                                                                                                                                                                        То, что майкрософты не углядели баг — не делает саму абстракцию плохой.

                                                                                                                                                                        Вы просили пример ситуации, когда понадобилось залезть в детали реализации, и потом за это поплатиться? Вы их получили.


                                                                                                                                                                        А чем плоха та аналогия?

                                                                                                                                                                        Тем, что архитектура — это не дом.


                                                                                                                                                                        Каким образом?

                                                                                                                                                                        Таким, что он уже заложился на другое поведение.


                                                                                                                                                                        В случае вырой имплементации, аспнет бы тоже ребилдился.

                                                                                                                                                                        Вы так этим восхищаетесь, как будто это что-то важное. Так вот — нет, не важное. А на билд-сервере все равно будет собираться все целиком.

                                                                                                                                                                          0
                                                                                                                                                                          Если это делать после разработки — то да, немного. Но тогда все время разработки я буду зависеть от имплементации.
                                                                                                                                                                          начальное.

                                                                                                                                                                          Я не понимаю, что вы спрашиваете.
                                                                                                                                                                          Почему вы говорите об имплементации абстракции, как что-то от третьей стороны, а от просто имплементации, как о чем то своем? В случае абстракции, вы сами же сможете заменить реализацию, так же, как вы собирались менять имплементацию.

                                                                                                                                                                          Это вы так говорите. А в реальности это далеко не всегда так, и это всегда приносит с собой дополнительные проблемы.
                                                                                                                                                                          ну мне это не принесло дополнительных проблем, а только облегчало жизнь, на протяжении 1,5 года ентерпрайз разработки. Согласен — может я когда-то наткнусь на эти проблемы, о которых вы знаете, в силу большего опыта. Но пока что, даже если это дает какие-то дополнительные сложности — профит перебивает все равно.

                                                                                                                                                                          Вы просили пример ситуации, когда понадобилось залезть в детали реализации, и потом за это поплатиться? Вы их получили.
                                                                                                                                                                          Вы привели пример БИТОЙ реализации. Приведите не битой, которая работает как-надо, а где проблему составила именно абстракция.

                                                                                                                                                                          Вы так этим восхищаетесь, как будто это что-то важное. Так вот — нет, не важное. А на билд-сервере все равно будет собираться все целиком.
                                                                                                                                                                          в случае разноса нагрузки — это очень поможет, потому что такие леера легче потом разбить на независимо деплоябельные компоненты.

                                                                                                                                                                          Тем, что архитектура — это не дом.
                                                                                                                                                                          Аналогия — это, вроде как, объяснение одних явление через другие, через схожесть по качествам и характеристикам явлений. То, что вы сказали сводить любую аналогию на 0.
                                                                                                                                                                            0
                                                                                                                                                                            начальное.

                                                                                                                                                                            Неа. Все то время, пока контракт не стабилизировался.


                                                                                                                                                                            Почему вы говорите об имплементации абстракции, как что-то от третьей стороны, а от просто имплементации, как о чем то своем?

                                                                                                                                                                            Потому что весь смысл абстракции в том, чтобы разделить "ту" и "эту" стороны.


                                                                                                                                                                            ну мне это не принесло дополнительных проблем, а только облегчало жизнь, на протяжении 1,5 года ентерпрайз разработки.

                                                                                                                                                                            Значит, вам повезло. Я, правда, более склонен думать, что вы просто не замечали приносимых проблем (как, например, вы игнорируете повышение сложности разработки и развертывания двух сервисов вместо одного), но это дело такое...


                                                                                                                                                                            Приведите не битой, которая работает как-надо, а где проблему составила именно абстракция.

                                                                                                                                                                            Уже приведенный пример с записью в файловую систему, которая неизвестно, когда произойдет, и вообще неизвестно, произойдет ли.


                                                                                                                                                                            в случае разноса нагрузки — это очень поможет, потому что такие леера легче потом разбить на независимо деплоябельные компоненты.

                                                                                                                                                                            Ха! Ох уж эта мне сказка про "локальное как удаленное и удаленное как локальное", которую я со времен слышу никак не позже, чем remoting выкатили, а то и раньше. Нет, так не выйдет. Код для локального и удаленного взаимодействия надо изначально проектировать по-разному.


                                                                                                                                                                            Аналогия — это, вроде как, объяснение одних явление через другие, через схожесть по качествам и характеристикам явлений.

                                                                                                                                                                            Вопрос в том, есть ли у двух приводимых вами явлений подходящие для обсуждения схожие характеристики.

                                                                                    0
                                                                                    где вообще искать это сообщение во втором случае?

                                                                                    Кажется должно быть очевидным, что сообщение меняется либо там, где оно выводится (а не там, где кидается эксепшн), либо вообще в системе локализации.

                                                                                    У меня другой вопрос к этому примеру: как пользователь попал именно в этот файл? Раскручивая цепочку вызовов? Не проще ли было осуществить поиск по самому сообщению (по неизменяемой его части)?
                                                                                      0
                                                                                      Кажется должно быть очевидным, что сообщение меняется либо там, где оно выводится

                                                                                      А где это место?


                                                                                      У меня другой вопрос к этому примеру: как пользователь попал именно в этот файл?

                                                                                      Это точка входа.


                                                                                      Не проще ли было осуществить поиск по самому сообщению

                                                                                      Конечно, проще. Но это автоматически делает бессмысленным заявление "архитектура дает нам ответ, где искать такой код".

                                                                                        0
                                                                                        Это точка входа.

                                                                                        Как он нашёл эту точку входа? Почему он искал именно её?

                                                                                        А где это место?

                                                                                        Вы мне скажите =) Если просто кинуть эксепшн и не обработать его, врят ли это сформирует корректный http-ответ клиенту (наверное, тут замешана какая-то абстракция? ;-))

                                                                                        Но это автоматически делает бессмысленным заявление «архитектура дает нам ответ, где искать такой код».

                                                                                        Не совсем так) Если бы у нас была «архитектура», то мы бы знали, что все строки хранятся там-то и там-то (в системе локализации, в константах с описанием ошибок / сообщений / etc), а не просто лежат раскатанные по всему коду.

                                                                                          0
                                                                                          Как он нашёл эту точку входа?

                                                                                          Зная конвеер обработки запроса в asp.net WebAPI


                                                                                          Почему он искал именно её?

                                                                                          Потому что в задаче было сказано, какой запрос выдает ошибку.


                                                                                          Если просто кинуть эксепшн и не обработать его, врят ли это сформирует корректный http-ответ клиенту

                                                                                          Это зависит от конвеера, некоторые конвееры вполне себе это делают.


                                                                                          Если бы у нас была «архитектура», то мы бы знали, что все строки хранятся там-то и там-то

                                                                                          Ну так я и задал вопрос, где они хранятся, если архитектура соответствует тому, что описано в статье. Ответа пока не получил.

                                                                                            0
                                                                                            Ответа пока не получил.

                                                                                            Ответ я уже дал (в константах / системе локализации).
                                                                                            Или Вы рассчитываете на какой-то ещё?

                                                                                            Потому что в задаче было сказано, какой запрос выдает ошибку.

                                                                                            Так почему не искать саму ошибку? Или получается, что мы вновь и вновь будем возвращаться во все места, где происходит валидация пароля пользователя (например, при регистрации нового) и исправлять эту ошибку ещё раз и ещё?

                                                                                            Это зависит от конвеера, некоторые конвееры вполне себе это делают.

                                                                                            Ну т.е. мы всё равно должны знать этот конкретный нюанс, чтобы пользоваться данным кодом? Тогда чем он лучше другого варианта, если он тоже подразумевает под собой некую неявность?
                                                                                              0
                                                                                              Ответ я уже дал (в константах / системе локализации).

                                                                                              Ну то есть в системе, построенной по правилам из статьи, эта строчка всегда будет в файле с константами, или в под системе локализации? Так?


                                                                                              Так почему не искать саму ошибку?

                                                                                              Можно искать саму ошибку. Вопрос — где.


                                                                                              Ну т.е. мы всё равно должны знать этот конкретный нюанс, чтобы пользоваться данным кодом?

                                                                                              Конечно. Нельзя пользоваться asp.net WebAPI, не зная его конвеера.


                                                                                              Тогда чем он лучше другого варианта, если он тоже подразумевает под собой некую неявность?

                                                                                              Тем, что когда выбирается asp.net WebAPI, он уже навязывает один набор соглашений. Предлагаемый подход навязывает… второй?

                                                                                                0
                                                                                                Ну то есть в системе, построенной по правилам из статьи, эта строчка всегда будет в файле с константами, или в под системе локализации? Так?

                                                                                                По правилам книги, часто изменяемые вещи должны быть сделаны максимально легко изменяемыми, если можно так выразиться. Самый идеальный случай — вообще без мешания программиста для всяких мелочей, типа поправить ошибку в строке.

                                                                                                Тем, что когда выбирается asp.net WebAPI, он уже навязывает один набор соглашений. Предлагаемый подход навязывает… второй?


                                                                                                Возможно, набор тех или иных соглашений — и есть часть архитектуры? Соглашения же не с бухты барахты делаются (я надеюсь), а имея какие-то предпосылки?
                                                                                                  0
                                                                                                  По правилам книги, часто изменяемые вещи должны быть сделаны максимально легко изменяемыми,

                                                                                                  А почему это "часто изменяемая вещь"? На мой взгляд, число таких символов меняется чаще, чем сообщение.


                                                                                                  Возможно, набор тех или иных соглашений — и есть часть архитектуры?

                                                                                                  Да, но… другой. В том смысле, что у вас есть архитектурные принципы фреймворка, с использованием которого написано приложение, а есть еще и те, которые вы для себя выбрали самостоятельно.

                                                                                                    0
                                                                                                    А почему это «часто изменяемая вещь»? На мой взгляд, число таких символов меняется чаще, чем сообщение.

                                                                                                    Ну, до тех пор, пока у вас это число хардкодится в сообщении, Вам придётся менять и его ;-)

                                                                                                    Если же не касаться конкретно этой строки, а вообще иметь в виду строки, которые должны отображаться пользователю, то в них периодически попадают ошибки, меняются формулировки, добавляются переводы.
                                                                                                      0
                                                                                                      Ну, до тех пор, пока у вас это число пишется в сообщении, Вам придётся менять и его

                                                                                                      Нет, я в первую очередь имею в виду число в условии этой проверки.


                                                                                                      то в них периодически попадают ошибки, меняются формулировки, добавляются переводы.

                                                                                                      "Периодически" — да. Чаще, чем в другом коде? Не обязательно.


                                                                                                      Но мы опять приходим к тому, что мест, где такие строки могут быть — сильно больше одного, и архитектурные правила из статьи не дают однозначного ответа на вопрос, где искать такую ошибку.

                                                                                                        0
                                                                                                        Нет, я в первую очередь имею в виду число в условии этой проверки.

                                                                                                        Т.е. Вы предлагаете изменить число и оставить строку такой же? Но ведь это приведёт к тому, что условие одно, а человеку пишется совсем о другом условии…

                                                                                                        и архитектурные правила из статьи не дают однозначного ответа на вопрос, где искать такую ошибку.

                                                                                                        статья лишь даёт неполный обзор на книгу, всё-таки можно сослаться на пункт сокрытие детали реализации.
                                                                                                        и в итоге у вас мухи (внутренние коды сообщений, например) отдельно, котлеты отдельно (способ хранения строк, привязанных к данному коду сообщения)

                                                                                                        соответственно, ошибку можно найти исходя из конкретной реализации этой абстракции, но в целом это выглядит примерно так:
                                                                                                        — спросить у народа где хранятся строки
                                                                                                        — найти там эту строку
                                                                                                          0
                                                                                                          Т.е. Вы предлагаете изменить число и оставить строку такой же?

                                                                                                          Нет, я говорю, что число меняется чаще. Можно сделать его параметром для строки, и дальше конструкция этого всего станет еще интереснее.


                                                                                                          на пункт сокрытие детали реализации.

                                                                                                          … который обычно затрудняет поиск чего-то, а не наоборот.


                                                                                                          но в целом это выглядит примерно так:
                                                                                                          • спросить у народа где хранятся строки

                                                                                                          Удивительно, но в системе, которая разработана не по правилам выше, будет так же — спросить где хранится, и там найти. Получается, что в данном примере выигрыша нет.

                                                                                                            0
                                                                                                            Удивительно, но в системе, которая разработана не по правилам выше, будет так же — спросить где хранится, и там найти. Получается, что в данном примере выигрыша нет.
                                                                                                            так вы раз спросите, потом будете знать где искать ту или иную логику. Без абстрагирования, эта логика может быть везде, проще искать в каком-то участке(модуль, папка..) или во ВСЕМ проекте?
                                                                                                              0
                                                                                                              так вы раз спросите, потом будете знать где искать ту или иную логику.

                                                                                                              Аналогично и без правил выше, "раз спросил, потом буду знать, где искать".


                                                                                                              Без абстрагирования, эта логика может быть везде

                                                                                                              С абстрагированием — тем более везде. Я вас как-то просил привести список архитектурно правильных мест, где может быть это сообщение, вы до сих пор этого так и не сделали.


                                                                                                              проще искать в каком-то участке(модуль, папка..) или во ВСЕМ проекте?

                                                                                                              Полнотекстовому поиску все равно.

                                                                                                                0
                                                                                                                С абстрагированием — тем более везде. Я вас как-то просил привести список архитектурно правильных мест, где может быть это сообщение, вы до сих пор этого так и не сделали.
                                                                                                                Я сделал это. Архитектура дает понять где что-то быть НЕ МОЖЕТ. А не где оно точно будет, ибо нету стандартов архитектуры, она может видоизменяться под нужды проекта.

                                                                                                                Полнотекстовому поиску все равно.
                                                                                                                Ну это пока проект не растет, и не усложняется
                                                                                                                  0
                                                                                                                  Архитектура дает понять где что-то быть НЕ МОЖЕТ.

                                                                                                                  И пользы с этого? Нам надо найти, где оно лежит, чтобы его поправить.


                                                                                                                  Ну это пока проект не растет, и не усложняется

                                                                                                                  И если вы мне хотите сказать, что с ростом проекта число мест, где может лежать строка, не увеличивается, вы меня обманываете (ну или не понимаете, как это работает).

                                                                                                                    0
                                                                                                                    И пользы с этого? Нам надо найти, где оно лежит, чтобы его поправить.
                                                                                                                    Искать проще

                                                                                                                    И если вы мне хотите сказать, что с ростом проекта число мест, где может лежать строка, не увеличивается, вы меня обманываете (ну или не понимаете, как это работает).
                                                                                                                    При адекватной архитектуре число мест должно остаться прежним, или же меньшим в сравнении неиспользования архитектуры
                                                                                                                      0
                                                                                                                      Искать проще

                                                                                                                      Чем проще-то? Полнотекстовому поиску, как уже говорилось, все равно, а вбивать в него исключения — лишний труд.


                                                                                                                      При адекватной архитектуре число мест должно остаться прежним, или же меньшим в сравнении неиспользования архитектуры

                                                                                                                      При адекватной — да. Но верно ли это утверждение для архитектуры, построенной по правилам из вашего поста? Не уверен.

                                                                                                                        0
                                                                                                                        При адекватной — да. Но верно ли это утверждение для архитектуры, построенной по правилам из вашего поста? Не уверен.
                                                                                                                        Конечно, нету никаких гарантий и стандартов.
                                                                                                                          0

                                                                                                                          … но при этом:


                                                                                                                          И вот как строить эту архитектуру, как избавится от головной боли при маленьком изменении требований от PM’а, или от стейкхолдера: об этом и поведает книга
                  0
                  Это все к тому, что красивые фразы «это все детали реализации» обычно так и остаются красивыми фразами, потому что суровая реальность намного сложнее, чем простые примеры.

                  Это конечно все так. Но не потому, что абстракция плохая и не работает. Чаще всего просто не хотят / не умеют четко разделять слои, считают что это слишком долго, дорого и т.д.

                  Тот же переход с реляционки на KV например. Если сразу правильно спроектировать слой доступа к данным, то там будет, например, для сущности Customer интерфейс с необходимыми для работы приложения методами.
                  interface CustomerRepository {
                    EntityCustomer getById(Long id);
                    EntityCustomer getByName(String name);
                    EntityCustomer getByManyManyAttrs(many many attrs ......);
                    EntityCustomer save(EntityCustomer entity);
                  ...............
                  }

                  Поменять реализацию этого интерфейса — поменяется хранилище. На что угодно. В том числе и на KV.
                  Да, там будет много проблем с поиском не по ключу, с объединением данных и т.д. и т.п. Это может действительно оказаться очень долго и дорого. Но! Это реализация только слоя хранения. Те самые «детали реализации». Все остальное уже разработано, протестировано. И трогать не надо ни бизнес логику, ни UI, ни что-то другое.

                  После такого перехода конечно же поменяются характеристики работы приложения, такие как скорость работы, максимальная нагрузка и т.д. и т.п. Все зависит от новой реализации.

                  Совершенно другой вопрос — откуда необходимость столь радикальной смены хранилища? Слишком суровый архитектурный косяк, imho.
                    0
                    Это конечно все так. Но не потому, что абстракция плохая и не работает.

                    Конечно. Это потому, что абстракции текут.


                    Если сразу правильно спроектировать слой доступа к данным

                    Как отличить правильно спроектированный слой доступа к данным от неправильно спроектированного?


                    поменяется хранилище. На что угодно. В том числе и на KV. [...] Все остальное уже разработано, протестировано.

                    Угу. Возьмем один метод, getById(id), и посмотрим на его свойства. getById(1) == getById(1)? А вот так: getById(1).name = 'def'; print(getById(1).name)? А вот так: getCustomerRepository().getById(1) == getCustomerRepository().getById(1)? А то же самое между потоками? А между процессами (передача сериализованных данных)?


                    Теперь добавим еще один метод: save(entity).


                    //thread 1
                    r1 = getCustomerRepository()
                    c1 = r1.get(1)
                    
                    //thread 2
                    r2 = getCustomerRepository()
                    c2 = r2.get(1)
                    
                    //thread 1
                    c1.name = 'def'
                    
                    //thread 2
                    c2.email = 'a@b.c'
                    r2.save(c2)

                    Что сохранится?


                    А теперь смотрите, в чем ловушка: совершенно не важно, какие ответы вы дадите. Важно другое — все эти ответы (и десятки других!) явно описаны где-то? На каждый из них есть тест? Или вы просто привыкли, что оно работает так?


                    Все остальное уже разработано, протестировано. И трогать не надо ни бизнес логику, ни UI, ни что-то другое. [...] После такого перехода конечно же поменяются характеристики работы приложения

                    Подождите. Вы же только что говорили, что все уже разработано и протестировано, а теперь говорите, что характеристики поменяются. Если поменялись характеристики — надо перетестировать, а если они стали неудовлетворительными — переписывать. И нет, переписывать только DAL окажется недостаточно. А это значит, ваша абстракция снова протекла.


                    Совершенно другой вопрос — откуда необходимость столь радикальной смены хранилища?

                    Я этот же вопрос задаю автору статьи, потому что это его утверждение, что все это можно поменять.


                    Слишком суровый архитектурный косяк

                    Занятно, не находите? Утверждается, что архитектура, которая позволяет поменять хранилище, хорошая, но необходимость поменять хранилище — архитектурный косяк.

                      0
                      Занятно, не находите? Утверждается, что архитектура, которая позволяет поменять хранилище, хорошая, но необходимость поменять хранилище — архитектурный косяк.


                      хочешь мира — готовься к войне

                      ну клиент, к примеру, может захотеть фичи какой-то, и из-за этого может быть придется менять хранилище, из-за того, что оно в каком-то роде не подходит
                        0
                        хочешь мира — готовься к войне

                        Стоимость этой подготовки посчитать не забыли?


                        ну клиент, к примеру, может захотеть фичи какой-то, и из-за этого может быть придется менять хранилище, из-за того, что оно в каком-то роде не подходит

                        А может не захотеть, а вы уже вложили ресурсы в подготовку к этой ситуации.


                        Ну и да, это не отменяет исходного вопроса: если вам пришлось поменять хранилище — это архитектурный косяк, или нет?

                          0
                          А может не захотеть, а вы уже вложили ресурсы в подготовку к этой ситуации.
                          ну а если внесет — ресурсы будут больше, насколько мне известно.

                          если вам пришлось поменять хранилище — это архитектурный косяк, или нет?
                          я думаю, тут однозначно сказать нельзя. Если изначально было выбрано хранилище, при том что был выбор лучше подходящего, нежели выбранное, то тогда — да. Если же к такому прибегают в следствии изменения реквайрментов от клиента, наверное — нет. Опять же вы хотите получить конкретный ответ на абстрактный вопрос. Я думаю, зависит от проекта, людей и ситуации.
                            0
                            ну а если внесет — ресурсы будут больше, насколько мне известно.

                            Я не понимаю, что вы хотите сказать.


                            Опять же вы хотите получить конкретный ответ на абстрактный вопрос.

                            Ну да, потому что из таких вопросов и состоит выбор архитектуры. Странно, да?

                              0
                              Ну да, потому что из таких вопросов и состоит выбор архитектуры. Странно, да?
                              так давайте конкретный пример и обсуждать, а не абстрактно говорить, если хотите не абстрактных и цикличных ответов.

                              ну а если внесет — ресурсы будут больше, насколько мне известно.

                              Если захочет внести эти изменения потом — они выйдут дороже, нежели подготовка к этим изменениям на раннем этапе проекта.(Ошибки проектирование — самые дорогие)
                                0
                                так давайте конкретный пример и обсуждать

                                Ну вот вам конкретный пример: я пишу веб-сервис (в том смысле, что он общается с внешним миром посредством JSON по HTTP), который должен обеспечивать полнотекстовый поиск по базе статей и отслеживать качество этого поиска на основании пользовательского отклика. Как мне оценить качество его архитектуры?


                                Если захочет внести эти изменения потом — они выйдут дороже

                                Ну да. Но потом, возможно, и деньги на это будут, в отличие от старта проекта.


                                Ошибки проектирование — самые дорогие

                                Вот только это не ошибка проектирования.

                                  0
                                  Ну вот вам конкретный пример: я пишу веб-сервис (в том смысле, что он общается с внешним миром посредством JSON по HTTP), который должен обеспечивать полнотекстовый поиск по базе статей и отслеживать качество этого поиска на основании пользовательского отклика. Как мне оценить качество его архитектуры?


                                  Я думаю, что на протяжении развития проекта, будут возникать новые требования на новые фичи, если текущая архитектура будет затруднять по ресурсам и времени их имплементацию. Во время обдумывания имплементации новых фич, вы осознаете, к примеру, что если бы я когда-то сделал по -другому, не было бы такой проблемы сейчас. И вот чем больше таких проблем — тем хуже архитектура, я думаю. А сразу оценку сделать, сложно я думаю. На то и придумали такие рекомендации как SOLID и Dependency Rule, что бы четко видеть, где может быть плохо сразу. По этому если ребята берут DDD, то держат домен независимым, по тому же Dependency rule. Хотя в в тот момент это может быть и не нужно, но для возможных будущих проблем это делается.
                                    0
                                    И вот чем больше таких проблем — тем хуже архитектура, я думаю.

                                    Вот только это будущее, а мне сейчас писать надо. Как мне сейчас писать?


                                    Я еще раз напомню вашу фразу из статьи:


                                    И вот как строить эту архитектуру, как избавится от головной боли при маленьком изменении требований от PM’а, или от стейкхолдера: об этом и поведает книга

                                    Так как же мне "строить эту архитектуру"?

                                      0
                                      Вот только это будущее, а мне сейчас писать надо. Как мне сейчас писать?

                                      Есть готовые решения, которые минимизируют возможность налажать, готовые принципы — которым можно следовать. В книге эти принципы и описаны.
                                        0

                                        Окей, возвращаемся на шаг раньше. Какие готовые решения и принципы надо применить при построении моего сервиса, и почему?

                                          0
                                          Ну как минимум SOLID, Reuse\release equivalenxe, common closure, common reuse principles, и ещё ряд рекомендаций, почему — там автор и говорит.
                                            0

                                            "Там автор и говорит" без цитаты не отвечает на мой вопрос.


                                            Например, расскажите мне, как именно я должен применить REP к своей задаче. Или, еще веселее, CCP — что именно является компонентом в моей задаче?

                                              0
                                              Например, расскажите мне, как именно я должен применить REP к своей задаче. Или, еще веселее, CCP — что именно является компонентом в моей задаче?

                                              окей, по CCP: если нужно полнотекстовый поиск — это отдельный кусок логики, который можно выделить как отдельный компонент:
                                              Gather into components those classes that change for the same reasons and at the same times.
                                              Потому что что запихнуть туда ещё и логику валидации — это виолейшн этого принципа — ибо валидация может менятся независимо от серч енджайна. Вот, один простенький пример
                                                0

                                                Гм. У меня весь код, отвечающий за полнотекстовый поиск — это формирование HTTP-запроса к ElasticSearch. Вы мне предлагаете его выделять в отдельный компонент?

                                                  0
                                                  Гм. У меня весь код, отвечающий за полнотекстовый поиск — это формирование HTTP-запроса к ElasticSearch. Вы мне предлагаете его выделять в отдельный компонент?
                                                  Да, потому что, допустим, потом появится реквайрмент считать количество запросов от юзера, илислать какой-то ивент на екстернал, когда серч енджайн тыкнули — это может призвести к виолейшн перечесленных принципов. Поэтому, я б вынес.
                                                    0

                                                    Почему для этого необходим отдельный компонент? Вы вообще помните определение компонента из книги, на которую вы ссылаетесь?

                                                  0

                                                  Ладно, давайте я попроще вопрос задам, чтобы на примере было. У меня есть две архитектуры-кандидата, между которыми я выбираю:


                                                  1. сервис на базе asp.net WebAPI, который принимает запросы от пользователей, отправляет их в ElasticSearch, отдает обратно отформатированными, принимает фидбек, пишет его в хранилище.
                                                  2. решение на базе AWS, где API Gateway принимает запрос, перекидывает его в Lambda, та прокидывает в эластик, а потом результаты обратно, фидбек идет напрямую через API Gateway в хранилище.

                                                  Какую архитектуру из двух мне выбрать и почему?

                                                    0
                                                    Я не знаю, как работает aws lamda. Поэтому я не знаю. Я бы выбрал первый, если это единственные реквайрменты.
                                                    Было бы два микросервиса, один на артиклы, другой на фидбек. Если нужно будет что-то дополнительное реализовать, мне будет проще это добавить. К примеру скажу что может поменятся. Артиклы могут расти, и хранить все в еластике станет лишним. Например, в моем проекте, все с серч енджайна тянется только айдиха, потом уже от модельки, мы подтягиваем необходимые данный с постгресса. Это к слову тоже отдельные логики, ибо постгрес может с легкостью сменится на MYSQL, к примеру. И что бы в одном методе не менять какой то синтаксис SQL, и редеплоить все — я поменяю это только в компоненте, отвечающего за доступ к бд.
                                                      0
                                                      Было бы два микросервиса, один на артиклы, другой на фидбек.

                                                      Почему два? Вы понимаете недостатки двух микросервисов?

                                                        0
                                                        Почему два? Вы понимаете недостатки двух микросервисов?
                                                        Да, понимаю. Это даст сложности в деплоинге, в разроботке, по финансам, о если говорить, о том случае, когда проект начнет расти — это окупится, потому что, скорее всего, на неё бы перешли при росте сложности.

                                                        Почему два? потому что принципиально разные ответственности и причины для изменения у них.
                                                          0
                                                          Это даст сложности в деплоинге, в разроботке, по финансам

                                                          Забыли латентность, а это для пользователя важнее всего.


                                                          если говорить, о том случае, когда проект начнет расти — это окупится

                                                          Не "когда", а "если". Если вы доживете до момента, когда проект начнет расти, а не погрязнете в разработке согласованного деплоя, системы коммуникации, протокола обмена с клиентом и прочих мелочей, которые вас тормозят.


                                                          Почему два? потому что принципиально разные ответственности и причины для изменения у них.

                                                          Вы понимаете, да, что у поискового микросервиса все равно больше одной причины для изменения (равно как, впрочем, и у микросервиса фидбека)?


                                                          (забавно при этом, что выше вы предлагали другую декомпозицию, но уже про нее забыли)

                                                            0
                                                            Забыли латентность, а это для пользователя важнее всего.


                                                            А как это повлияет на латентность?

                                                            Не «когда», а «если». Если вы доживете до момента, когда проект начнет расти, а не погрязнете в разработке согласованного деплоя, системы коммуникации, протокола обмена с клиентом и прочих мелочей, которые вас тормозят.


                                                            Я думаю это уже совсем другой вопрос. Естественно, для этого архитекторы собираются с ПМами и т.д., что бы оценить риски, и стоит ли делать вот так и все сразу, или что-то пока что оставить на потом.

                                                            (забавно при этом, что выше вы предлагали другую декомпозицию, но уже про нее забыли)

                                                            имелась в виду эта, может я не правильно выразился
                                                              0
                                                              А как это повлияет на латентность?

                                                              Вообще-то, она увеличится, потому что вместо обращения к одному компоненту будет обращение к двум, а пересечение границы компонента — это дорого.


                                                              Естественно, для этого архитекторы собираются с ПМами и т.д., что бы оценить риски, и стоит ли делать вот так и все сразу, или что-то пока что оставить на потом.

                                                              … и если они оценят иначе, то ваша архитектура перестанет быть правильной, и станет правильной какая-то другая?


                                                              Мне, конечно, нравится, как вы элегантно проигнорировали нарушение CCP в вашей декомпозиции (а при этом продолжаете говорить, что нарушение SRP в классе — это плохо).

                                                                0
                                                                Вообще-то, она увеличится, потому что вместо обращения к одному компоненту будет обращение к двум, а пересечение границы компонента — это дорого.
                                                                в контексте задачи — это все равно два различных запроса. Какая разница обращаться на два сервака, или на один? Или вы хотели впихнуть в один запрос и сохранение фидбека и доставание артиклов??
                                                                … и если они оценят иначе, то ваша архитектура перестанет быть правильной, и станет правильной какая-то другая?

                                                                нет, она станет не релевантная в данном случае.
                                                                Мне, конечно, нравится, как вы элегантно проигнорировали нарушение CCP в вашей декомпозиции (а при этом продолжаете говорить, что нарушение SRP в классе — это плохо).
                                                                вполне может быть — я не архитектор, и когда привел пример, я не советовался вообще ни с кем, а с потолка взял то, что первое в голову пришло. Где же там нарушение?
                                                                  0
                                                                  в контексте задачи — это все равно два различных запроса.

                                                                  Неа, первый фидбек пишется в момент прохождения запроса в полнотекстовый поиск (чтобы сам факт запроса фиксировать).


                                                                  нет, она станет не релевантная в данном случае.

                                                                  Вот видите. Вы все сделали по вашим правилам, а архитектура все равно "не релевантная".


                                                                  Где же там нарушение?

                                                                  Там, где каждый ваш компонент имеет больше одной причины для изменения.

                                                                    0
                                                                    Неа, первый фидбек пишется в момент прохождения запроса в полнотекстовый поиск (чтобы сам факт запроса фиксировать).
                                                                    тогда прошу прощения, я имел в виду фидбек — как отдельная сущность отзыва клиента о системе, без контекста артиклов.

                                                                    Вот видите. Вы все сделали по вашим правилам, а архитектура все равно «не релевантная».


                                                                    Но такого разговора не было, никто ничего не решил — поэтому ещё не не релевантная. Просто когда обсуждали проект, в котором я — приняли, например, решение писать на микросервисах — и сейчас я понимаю, что если бы не приняли — были бы сложности.

                                                                    Там, где каждый ваш компонент имеет больше одной причины для изменения.
                                                                    И какая там причина изменения кроме причины изменения связанная с серч енджайном?
                                                                      0
                                                                      тогда прошу прощения, я имел в виду фидбек — как отдельная сущность отзыва клиента о системе, без контекста артиклов.

                                                                      Нет, это фидбек о работе поиска, в контексте конкретных результатов. Так что, будете архитектуру менять?


                                                                      Но такого разговора не было, никто ничего не решил — поэтому ещё не не релевантная.

                                                                      … но до такого разговора нельзя принять решение о выборе архитектуры.


                                                                      И какая там причина изменения кроме причины изменения связанная с серч енджайном?

                                                                      У сервиса полнотекстового поиска:


                                                                      • смена контракта поискового движка
                                                                      • смена клиентского контракта
                                                                      • смена поведения
                                                                      • смена контракта сервиса фидбека

                                                                      У сервиса фидбека:


                                                                      • смена контракта хранилища
                                                                      • смена клиентского контракта
                                                                      • смена бизнес-логики

                                                                      (я, заметим, еще не факт, что все вспомнил)

                                                                        0
                                                                        смена контракта сервиса фидбека
                                                                        вот эта ответственность и всплывает, когда набросать все в один метод. Если посыл фидбека вынести как отдельный клас с интерфейсом — эта ответственность пропадает. По серч енджайну, все это можно запихнуть в единую абстракцию аля (дай мне статьи по такому слову), и все, а в имплементации мы можем и сфинкс тогда юзнуть. Код контроллера примерный:

                                                                        public async Task<List<Article>> GetArticlesAsync(string searchWord){
                                                                        var articles = _engineAbs.GetArticlesBySearchWord(searchWord);
                                                                        _externalInteractor.SendFeedback();
                                                                        }


                                                                        Теперь изменения в посыле фидбека никак не влияет на гет статей.
                                                                          0
                                                                          вот эта ответственность и всплывает, когда набросать все в один метод.

                                                                          А какая разница, в скольких оно методах, мы про компоненты говорим.


                                                                          Если посыл фидбека вынести как отдельный клас с интерфейсом — эта ответственность пропадает.

                                                                          Никуда она не пропадает, она все так же в том же компоненте. В другом классе, но в том же компоненте.


                                                                          Я вас еще раз спрошу: вы вообще помните определение компонента из книги, на которую вы ссылаетесь?

                                                                            0
                                                                            Никуда она не пропадает, она все так же в том же компоненте. В другом классе, но в том же компоненте.

                                                                            Ну в данном случае, я бы реализовал посыл по нетворку какого-то меседжа в отдельной библиотеке, а это — компонент, потому что ее можно отдельно задеплоить.

                                                                            Тут я за компонент забыл, но вспомнил. Даже на уровне классов и методов принципы остаются рабочими. Пропадает только фича независимого деплоинга.
                                                                              0
                                                                              Ну в данном случае, я бы реализовал посыл по нетворку какого-то меседжа в отдельной библиотеке, а это — компонент, потому что ее можно отдельно задеплоить.

                                                                              Теперь у вас появился контракт между этим компонентом и вашим. Компонентов стало больше, контрактов стало больше, но проблема никуда не исчезла.


                                                                              потому что ее можно отдельно задеплоить.

                                                                              Но вообще, конечно, нельзя. Деплоить надо релиз целиком, потому что REP.


                                                                              Даже на уровне классов и методов принципы остаются рабочими.

                                                                              На уровне классов и компонентов этот принцип называется SRP, и там ровно те же проблемы, просто с другими словами.

                                                                                0
                                                                                Теперь у вас появился контракт между этим компонентом и вашим. Компонентов стало больше, контрактов стало больше, но проблема никуда не исчезла.

                                                                                но через инвертирование зависимостей все стает независимым, независимо деплоябельным, и независимо девелопабильным. Так или иначе эти же контракты остаются, будучи в одном компоненте.

                                                                                Но вообще, конечно, нельзя. Деплоить надо релиз целиком, потому что REP
                                                                                Почему?? если н е устраивает фидбек, или его нужно слать ещё в одно место, к примеру, что мешает написать эту логику, и задеплоить только этот микросервис??? Именно поэтому он и был разделён, по этому же принципу, что бы так можно было сделать. В случае вашем же, редеплоить пришлось бы и артиклы, просто потому, что архитектура хуже бы была, а почему? потому что этот принцип (REP) не соблюден.

                                                                                На уровне классов и компонентов этот принцип называется SRP, и там ровно те же проблемы, просто с другими словами.
                                                                                для того придумали Dependency Inversion.
                                                                                  0
                                                                                  но через инвертирование зависимостей все стает независимым, независимо деплоябельным, и независимо девелопабильным.

                                                                                  Нет, не станет.


                                                                                  Чтобы у вас появилась независимая разработка, вам надо разнести это по разным проектам, положить каждый в независимый версионник и настроить там сборку (желательно вместе с CI, чего уж). И это не забыв про то, что вам надо как-то прокинуть общеиспользуемый интерфейс между этими двумя проектами.


                                                                                  Чтобы у вас появилось независимое развертывание, вам нужно для каждого проекта сделать свое версионирование (не путать с хранилищем версий) и конвеер развертывания, и не забыть добавить проверки, чтобы у вас не оказалось в одном окружении несовместимых версий. А, и да, если вас волнует высокая доступность, то каждая точка развертывания должна иметь механизм развертывания без прекращения обслуживания, и удачи вам в выполнении этого с взаимнозависимыми "независимыми" компонентами.


                                                                                  А теперь вопрос — зачем мне это? Зачем мне "независимая разработка" для функциональности размером в десять строк кода? Зачем мне независимое развертывание для куска кода, который служит тонкой прослойкой между остальным кодом и ElasticSearch? Что я такого получу, что объяснит моему заказчику, почему я потратил на это в два с половиной раза больше ресурсов?


                                                                                  И знаете, что самое грустное? Что CCP все равно нарушен.


                                                                                  Почему?

                                                                                  Потому что нормальная единица развертывания для asp.net-сервиса — это сервис целиком, а не отдельные сборки внутри него. Если вы хотите подменять сборки по отдельности, вам придется сколхозить собственный набор механизмов доставки и обновления.


                                                                                  если н е устраивает фидбек, или его нужно слать ещё в одно место, к примеру, что мешает написать эту логику, и задеплоить только этот микросервис?

                                                                                  Напомню, что мы говорим про поисковый "микросервис", который вы недавно предложили разбить на несколько компонентов. До фидбека мы еще не дошли (хотя в нем будет все то же самое).


                                                                                  для того придумали Dependency Inversion.

                                                                                  Для чего именно "того"?

                                                                                    0
                                                                                    А теперь вопрос — зачем мне это? Зачем мне «независимая разработка» для функциональности размером в десять строк кода?
                                                                                    ну тут мы говорим о рентабельности того или инного подхода, а не о том, что он плохой.

                                                                                    Касательно зависимости фидбека и артаклов. Окей, вы предлагаете иметь все в одной сборке. Теперь предположим, у вас появился сервис юзеров, там тоже нужно делать фидбек(слать меседж в какой-то екстернал сервис). Эта логика уже есть в артиклах, вы предлагаете это копипастить, или же юзеры теперь будут зависим компонентом от артиклов?

                                                                                    Для чего именно «того»?
                                                                                    для того, чтобы убрать явные зависимости, и сделать компонент независимым от деталей реализации.(в статье есть картинка) — это работает на масштабах объекта, компонента, и сервисов в целом.

                                                                                    Потому что нормальная единица развертывания для asp.net-сервиса — это сервис целиком, а не отдельные сборки внутри него. Если вы хотите подменять сборки по отдельности, вам придется сколхозить собственный набор механизмов доставки и обновления.
                                                                                    Можно это сделать через РЕСТ, объявить фидбек, как интернальный микросервис, и все делать через него, и мы сможем независимо деплоить его.
                                                                                      0
                                                                                      ну тут мы говорим о рентабельности того или инного подхода, а не о том, что он плохой.

                                                                                      А разве можно считать хорошим нерентабельный подход?


                                                                                      Касательно зависимости фидбека и артаклов.

                                                                                      Вы опять переводите тему. Нет, не касательно "зависимости фидбека и артаклов". Меня интересует только выделенный вами микросервис поиска, который — в вашей декомпозиции! — нарушает CCP. Про фидбек поговорим потом.


                                                                                      Окей, вы предлагаете иметь все в одной сборке.

                                                                                      Нет, не предлагаю.


                                                                                      для того, чтобы убрать явные зависимости

                                                                                      Вы мне хотите сказать, что код, использующий интерфейс, не имеет явной зависимости от этого интерфейса?


                                                                                      Можно это сделать через РЕСТ, объявить фидбек, как интернальный микросервис

                                                                                      Я еще раз повторю, мне не сложно: мы. говорим. не. про. фидбек. Мы говорим про один микросервис поиска по статьям.

                                                                                        0
                                                                                        А разве можно считать хорошим нерентабельный подход?
                                                                                        Конечно, хорошесть определяеться ресурсами. Или вы хотите сказать, что к примеру огромный дом, где то в центре города хуже, старой обшарпаной квартиры, только потому, что он дороже? Нет — он по многим признакам лучше будет, вопрос в деньгах.

                                                                                        Вы опять переводите тему. Нет, не касательно «зависимости фидбека и артиклов». Меня интересует только выделенный вами микросервис поиска, который — в вашей декомпозиции! — нарушает CCP. Про фидбек поговорим потом.

                                                                                        Окей уберем фидбек, есть сервис, который отвечает только за артиклы(полнотекстовый поиск), где здесь виолейшн? Пришел запрос на вебсервис, пошел на абстракцию серч енджайна — вернул данные, где тут виолейшн ССP?

                                                                                        Вы мне хотите сказать, что код, использующий интерфейс, не имеет явной зависимости от этого интерфейса?
                                                                                        Да. Таким образом и строится архитектура по ДДД, абстракция репозитория в домене, и домен неимеет явных зависимостей на инфраструктуру.

                                                                                        Я еще раз повторю, мне не сложно: мы. говорим. не. про. фидбек. Мы говорим про один микросервис поиска по статьям.
                                                                                        в этом же ответе выше.
                                                                                          0
                                                                                          Или вы хотите сказать, что к примеру огромный дом, где то в центре города хуже, старой обшарпаной квартиры, только потому, что он дороже?

                                                                                          Если я не могу его купить, он для меня хуже. Аналогично, если бизнес не можете себе позволить архитектуру, значит, эта архитектура хуже для этого бизнеса, чем другая.


                                                                                          Окей уберем фидбек, есть сервис, который отвечает только за артиклы(полнотекстовый поиск), где здесь виолейшн? Пришел запрос на вебсервис, пошел на абстракцию серч енджайна — вернул данные, где тут виолейшн ССP?

                                                                                          Там, где у этого сервиса как минимум четыре причины для изменения, совершенно разных по времени.


                                                                                          Вы мне хотите сказать, что код, использующий интерфейс, не имеет явной зависимости от этого интерфейса?
                                                                                          Да.

                                                                                          Гм.


                                                                                          class Some
                                                                                          {
                                                                                            IDependency _dependency;
                                                                                          }

                                                                                          Вы мне хотите сказать, что у класса Some нет явной зависимости от интерфейса IDependency?


                                                                                          Таким образом и строится архитектура по ДДД, абстракция репозитория в домене, и домен неимеет явных зависимостей на инфраструктуру.

                                                                                          Вот только и домен, и инфраструктура имеют явную зависимость от этой абстракции. А это именно то, о чем я вас спрашивал.

                                                                                            0
                                                                                            Если я не могу его купить, он для меня хуже. Аналогично, если бизнес не можете себе позволить архитектуру, значит, эта архитектура хуже для этого бизнеса, чем другая.
                                                                                            Ну так вы хотите получить объективный ответ на субъективный вопрос. Да, вашем случае хуже, в другом может быть лучше. Как вы хотите получить объективную характеристику в субъективном вопросе.
                                                                                            Вы мне хотите сказать, что у класса Some нет явной зависимости от интерфейса IDependency?

                                                                                            а вы в том же неймспейсе оставьте интерфейс — и не будет зависимости.

                                                                                            Вот только и домен, и инфраструктура имеют явную зависимость от этой абстракции. А это именно то, о чем я вас спрашивал.
                                                                                            Инфраструктура — имеет, домен нет. Домен независим от остальных лееров при этом.
                                                                                              0
                                                                                              Ну так вы хотите получить объективный ответ на субъективный вопрос.

                                                                                              Почему же, вполне объективный. Наличие ресурсов — это объективный фактор.


                                                                                              а вы в том же неймспейсе оставьте интерфейс — и не будет зависимости.

                                                                                              Никуда она не денется. Не важно, где интерфейс, если интерфейса нет — код не скомпилируется.


                                                                                              Инфраструктура — имеет, домен нет.

                                                                                              Оба имеют.


                                                                                              Домен независим от остальных лееров при этом.

                                                                                              Ну да, от других слоев он теоретически независим. И что?


                                                                                              Я так понимаю, вы на нарушение CCP забили? Оказался неважный принцип?

                                                                                                0
                                                                                                Никуда она не денется. Не важно, где интерфейс, если интерфейса нет — код не скомпилируется.
                                                                                                Так если интерфейса нет — нету и абстракции. В таком случае, можно говорить, о зависимости метода, следовательно класса, следовательно компонента от локальной переменной.

                                                                                                Хотя, если так все сложить, как вы сказали — действительно зависимость будет. Но причин для изменения абстракции меньше — нежели имплементации. Абстракция стабильнее, именно поэтому зависимость на ней, а не на деталях реализации. Об этом, к слову, автор книги тоже говорит.
                                                                                                Почему же, вполне объективный. Наличие ресурсов — это объективный фактор.
                                                                                                Вернемся обратно к аналогии с домом и квартирой, от количества ресурсов, сам дом и квартира лучше не станут, или хуже. Они уже такие, какие есть.

                                                                                                «независимость суждений, мнений, представлений и т.п. от субъекта, его взглядов, интересов, вкусов, предпочтений и т.д. (противоположность — субъективность). О. означает способность не предвзято и без предрассудков вникать в содержание дела, представлять объект так, как он существует сам по себе» с словаря — ключевое слово
                                                                                                объект так, как он существует сам по себе
                                                                                                . Дом, САМ ПО СЕБЕ, а не в контексте сколько у вас есть бюджета.

                                                                                                Я так понимаю, вы на нарушение CCP забили? Оказался неважный принцип?
                                                                                                как по мне, там нету виолейшна, сервис один, в себе имеет логику, которая связанна с полнотекстовым поиском.

                                                                                                Ну да, от других слоев он теоретически независим. И что?
                                                                                                Независимость слоев — это тоже архитектура. Она дают простоту, изолирует один слой от другого, делает независимость одного слоя от другого, и логически связывает логику в одном. слое.
                                                                                                  0
                                                                                                  Абстракция стабильнее, именно поэтому зависимость на ней, а не на деталях реализации.

                                                                                                  Не на этапе разработки. Но спасибо, кэп, да.


                                                                                                  Дом, САМ ПО СЕБЕ, а не в контексте сколько у вас есть бюджета.

                                                                                                  Архитектура не существует сама по себе.


                                                                                                  как по мне, там нету виолейшна, сервис один, в себе имеет логику, которая связанна с полнотекстовым поиском.

                                                                                                  Я то же самое могу сказать про ситуацию, когда вообще все сделано в одном сервисе: "сервис один, в себе имеет логику, которая связана с полнотекстовым поиском". Будет ли это означать, что сделать все в одном сервисе не нарушает CCP?


                                                                                                  Независимость слоев — это тоже архитектура. Она дают простоту, изолирует один слой от другого, делает независимость одного слоя от другого

                                                                                                  Независимость слоев делает независимость слоев. Угу. Зачем мне это?


                                                                                                  Ваше утверждение "дает простоту" ничем не подтверждено. Вы это говорите, но на примере конкретной задачи все предлагаемые вами принципы только усложняют решение.


                                                                                                  логически связывает логику в одном. слое.

                                                                                                  Неа. Независимость слоев никак не влияет на логическую связность логики в одном слое.

                                                                                                    0
                                                                                                    Не на этапе разработки. Но спасибо, кэп, да.
                                                                                                    а на этапе продакшна — уже да. Пожалуйста.
                                                                                                    Архитектура не существует сама по себе.
                                                                                                    почему же?

                                                                                                    «сервис один, в себе имеет логику, которая связана с полнотекстовым поиском». Будет ли это означать, что сделать все в одном сервисе не нарушает CCP?
                                                                                                    Нет, потому, что в вашем случае логика будет на посыл фидбека. А в моем, только артиклы.

                                                                                                    Независимость слоев делает независимость слоев. Угу. Зачем мне это?
                                                                                                    Она дают простоту, изолирует один слой от другого, делает независимость одного слоя от другого


                                                                                                    Неа. Независимость слоев никак не влияет на логическую связность логики в одном слое.
                                                                                                    ну вы когда пишете слой — пишете связанную логично там логику.
                                                                                                      0
                                                                                                      а на этапе продакшна — уже да.

                                                                                                      А на этапе продакшна уже и трогать не надо. Пусть работает.


                                                                                                      почему же?

                                                                                                      Потому что она призвана выполнять задачу. Без задачи это просто чьи-то размышления о благом.


                                                                                                      А в моем, только артиклы.

                                                                                                      Во-первых, нет, не только артиклы — еще отправка фидбека по запросам.


                                                                                                      А во-вторых, CCP формулируется не в терминах логики, а в терминах причин для изменения: "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."


                                                                                                      Или это так, несущественные мелочи?

                                                                                                        0
                                                                                                        А на этапе продакшна уже и трогать не надо. Пусть работает.
                                                                                                        Не совсем так можно «не трогать», могут реквайрменты поменяться, данные имеют свойство расти и т.д.

                                                                                                        Потому что она призвана выполнять задачу. Без задачи это просто чьи-то размышления о благом.
                                                                                                        выполнять задачу — это о поведении апликейшна, а архитектура — это о другом, о чем, спросите? — я это выше говорил.

                                                                                                        Во-первых, нет, не только артиклы — еще отправка фидбека по запросам.
                                                                                                        я говорю оо артиклах без фидбека. Если фидбек включать, я уже говорил, что это был бы отдельный рест скорее всего.

                                                                                                        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
                                                                                                        Все правильно, сервис артиклов — отправляет запрос на серч енджайн — выдает респонс. Если отправлять фидбек — то через абстракцию, — это не ответственность артиклов, потому что они бы не имели имплементации фидбеков.
                                                                                                          0
                                                                                                          Не совсем так можно «не трогать», могут реквайрменты поменяться, данные имеют свойство расти и т.д.

                                                                                                          … и в этот момент снова не понятно, то ли надо имплементацию менять, а то ли интерфейс трогать.


                                                                                                          выполнять задачу — это о поведении апликейшна, а архитектура — это о другом

                                                                                                          Неа. Архитектура должна выполнять задачу, которую перед ней поставили. Поддерживать расширяемость — задача. Поддерживать тестируемость — задача. Позволять работать в облаке — задача. Ну и так далее...


                                                                                                          я говорю оо артиклах без фидбека. Если фидбек включать, я уже говорил, что это был бы отдельный рест скорее всего.

                                                                                                          Вы не понимаете. Он отправляет фидбек о том, какие запросы были сделаны. Он должен это делать.


                                                                                                          Все правильно, сервис артиклов — отправляет запрос на серч енджайн — выдает респонс.

                                                                                                          "Все правильно" — это сколько у него причин для изменения?

                                                                                                            0
                                                                                                            … и в этот момент снова не понятно, то ли надо имплементацию менять, а то ли интерфейс трогать
                                                                                                            .Интерфейс -стабильнее, поэтому чаще всего — имплементацию.

                                                                                                            Поддерживать расширяемость — задача. Поддерживать тестируемость — задача. Позволять работать в облаке — задача. Ну и так далее...
                                                                                                            ааа, я вас неправильно понял. С этим полностью солидарен. Кстати говоря, тестировать то проще с абстракциями и интерфейсами. Расширять — тоже проще с абстракциями.

                                                                                                            Вы не понимаете. Он отправляет фидбек о том, какие запросы были сделаны. Он должен это делать
                                                                                                            Ну в моем случае будет отдельный сервис(по сути класс с интерфейсом), который будет иметь метод — отправить фидбек. Можно сделать отдельную либу, которая будет отправлять что-то наружу. И заюзать ее. Сервис будет делать тоже — возвращать артиклы, только ещё к тому, на каком-то интерфейсе вызывать _externalInteractor.SendMessage(string message). он не будет имплементить это, он просто вызовет метод. Если нужно будет, потом леер, который отвечает за отправку меседжа можно изменять, дополнять — что угодно. Только это будет проще, нежели искать эту имплементацию в методе, где с статьями работают.

                                                                                                            «Все правильно» — это сколько у него причин для изменения?
                                                                                                            причина — изменение логики, либо чего-то связанного с серч енджайном. Сервис по себе не зависит от посыла фидбек, ибо он это не имплементит.
                                                                                                              0
                                                                                                              Интерфейс -стабильнее, поэтому чаще всего — имплементацию.

                                                                                                              Если речь идет об изменении требований, то это, скажем так, не очень предсказуемо. Потому что неизвестно, заложили вы (неизвестные) новые требования в свой интерфейс, или нет.


                                                                                                              ааа, я вас неправильно понял. С этим полностью солидарен.

                                                                                                              … так вот, "должно быть можно разработать нашими силами за месяц" — такая же задача. Если архитектура ее не решает, то это плохая архитектура, негодная.


                                                                                                              Ну в моем случае будет отдельный сервис(по сути класс с интерфейсом), который будет иметь метод — отправить фидбек. Можно сделать отдельную либу, которая будет отправлять что-то наружу. И заюзать ее.

                                                                                                              Это никак не повлияет на количество причин для изменения компонента в целом.


                                                                                                              причина — изменение логики, либо чего-то связанного с серч енджайном.

                                                                                                              Во-первых, это уже две причины, и они происходят в разное время. А во-вторых, вы забыли изменение клиентского контракта, изменение требований на фидбек (=что сохраняется) и изменение контракта с сервисом фидбека. Итого минимум четыре, а на самом деле — больше пяти. Явное, явное нарушение CCP в том виде, в котором он сформулирован.


                                                                                                              Я вам больше того скажу, разделение сервисов статей и фидбека — это нарушение первой части CCP ("Gather into components those classes that change for the same reasons and at the same times. ")

                                                                                                                0
                                                                                                                … так вот, «должно быть можно разработать нашими силами за месяц» — такая же задача. Если архитектура ее не решает, то это плохая архитектура, негодная.
                                                                                                                негодная в одном случае — годная в другом. Это зависит от многих факторов, но сама по себе, она может быть хорошая, хоть и не рентабельна в некоторых случаях.
                                                                                                                Это никак не повлияет на количество причин для изменения компонента в целом.
                                                                                                                Нет, повлияет. Либа — отдельный, изолированный компонент. Ее с легкостью потом можно поставить в РЕСТ. И тогда — это повлияет. Только вот легче это сделать имея абстракцию, а не лазить по всем артиклам в поисках отправки фидбека.

                                                                                                                Во-первых, это уже две причины, и они происходят в разное время.
                                                                                                                Нет, это причина измения полнотектового поиска, она одна.
                                                                                                                вы забыли изменение клиентского контракта, изменение требований на фидбек
                                                                                                                В случае, если фидбек отдельный сервис, тогда опять таки нет. Фидбек: просто набор меседжа, стринга какая-то и все. Если от фидбека нужно будет изменение, например писать ещё все фидбеки в базу, то это не повлияет на артиклы.

                                                                                                                Я вам больше того скажу, разделение сервисов статей и фидбека — это нарушение первой части CCP
                                                                                                                Ну и каким образом. Я хочу добавить логику, кроме отправки фидбека наружу, писать все из в бд. Зачем мне нужно изменять что-то в артиклах по этому поводу? То есть изменения на фидбек, которое не трогает артиклы. Мне кажется это не «classes that change for the same reasons and at the same times»
                                                                                                                  0
                                                                                                                  негодная в одном случае — годная в другом.

                                                                                                                  Так зачем мне архитектура, которая не подходит к моей задаче?


                                                                                                                  Нет, повлияет. Либа — отдельный, изолированный компонент.

                                                                                                                  Нет. Только в том случае, если она разворачивается отдельно. а это для обычной библиотеки не так.


                                                                                                                  Ее с легкостью потом можно поставить в РЕСТ.

                                                                                                                  Неа, нельзя.


                                                                                                                  Нет, это причина измения полнотектового поиска, она одна.

                                                                                                                  Ну как же так. Изменились бизнес-требования — раз. Изменился сервис полнотекстового поиска — два. Это происходит в разное время и по разным причинам.


                                                                                                                  В случае, если фидбек отдельный сервис, тогда опять таки нет.

                                                                                                                  Фидбек-то отдельный сервис, но мне в него надо писать в конкретное время и по конкретным условиям, а они — часть сервиса поиска.


                                                                                                                  Фидбек: просто набор меседжа, стринга какая-то и все.

                                                                                                                  Вот-вот. Сначало было "стринга такая-то", а потом решили добавить кокнретного пользователя, который это сделал. В скольких местах придется поменять?


                                                                                                                  Ну и каким образом.

                                                                                                                  Очень простым: вы хотите добавить в контракт фидбека новое поле, см. выше. В скольких местах придется поменять?

                                                                                                                    0
                                                                                                                    Так зачем мне архитектура, которая не подходит к моей задаче?
                                                                                                                    так не используйте, но от того, что вы её не используете, она хуже не станет.
                                                                                                                    Неа, нельзя.
                                                                                                                    Можно: перемещаешь имплементацию с абстракцией в новый рест сервис, и накатываешь для этого ХТТП запросы. Вуаля. Но только перетащить два файла — это не копаться во всех артиклах, в поисках отпраки фидбека.

                                                                                                                    Изменились бизнес-требования
                                                                                                                    при чем бизнес требования к серч енджайну — он выполняет поиск по текст в статьях и все.
                                                                                                                    Фидбек-то отдельный сервис, но мне в него надо писать в конкретное время и по конкретным условиям, а они — часть сервиса поиска.
                                                                                                                    ток киньте это в джсон и отпраьте на рест(в фидбек). Фидбек сервису будет все равно, что ему отправят — он получил и на екстернал сервис какой-то отправил. Все.

                                                                                                                    Вот-вот. Сначало было «стринга такая-то», а потом решили добавить кокнретного пользователя, который это сделал. В скольких местах придется поменять?
                                                                                                                    для этого джсон енкодинг придумали. Все равно стринга.

                                                                                                                    Очень простым: вы хотите добавить в контракт фидбека новое поле, см. выше. В скольких местах придется поменять?
                                                                                                                    ДЖСОООН. Любую модельку сконвертили, и отправили как стрингу.
                                                                                                                      0
                                                                                                                      так не используйте, но от того, что вы её не используете, она хуже не станет.

                                                                                                                      Повторяю еще раз: архитектура, которую я не могу использовать, для меня плохая. Потому что ни зачем не нужна.


                                                                                                                      Можно: перемещаешь имплементацию с абстракцией в новый рест сервис, и накатываешь для этого ХТТП запросы.

                                                                                                                      … а потом выясняешь, что один из параметров запроса — Func<T>, и смотришь, как прекрасно он сериализуется. Или, что проще, видишь, что метод вызывался настолько часто, что из-за дополнительных расходов на HTTP система замедлилась вдвое.


                                                                                                                      при чем бизнес требования к серч енджайну — он выполняет поиск по текст в статьях и все.

                                                                                                                      Ага, "и все". А то, по каким конкретно полям, и с каким весами? А дополнительные фильтры? Ну и самое главное — реранкинг, сейчас — общий, а в будущем — с учетом пользователя?


                                                                                                                      Если бы не было бизнес-требований, не было бы и сервиса.


                                                                                                                      ток киньте это в джсон и отпраьте на рест(в фидбек).

                                                                                                                      У вас все сервисы между собой общаются по нетипизированным контрактам?


                                                                                                                      Впрочем, даже если это так, при переходе с JSON-over-HTTP на шину сообщений код придется править в двух местах.