У меня сложилось ощущение что весь их спор - из-за разного подхода к необходимости написания тестов. Мартин изначально пишет под тесты, его подход так и выглядит - много мелких объектов/функций.
А главное - газовая труба со счетчиком на дальней стене! С ними что-то сделать - это же боль. Нет, это БОЛЬ. А тут рррраз - и нет труб) AI - сила! Впрочем, это явно кухня а дизайн под гостиную, наверно неудачный пример помещения. Иначе, где гарнитур-то? Видимо справа за углом пара модулей на 60) Чисто руки помыть и винишко открыть, а еду можно и в ресторанах заказать (вот это жена точно одобрит)
Про точки, тире, пробелы - для меня прям откровение. С точками так смешно: всегда подозревал что есть какой-то правильный красивый подход но никак не мог заняться поиском, да даже проблему не мог сформулировать для себя, вижу что "не айс", а что понять не мог.
Спринты есть, если что. Задачи можно доской можно кантом смотреть. Иерархия вложенными задачами делается. Это так, на вскидку. По остальному не скажу. Trello - бледная копия по сравнению с, так-то.
Ну вы статью прочтите хоть. Там в разделе "Микросервисы" приведена структура приложения. Только в модуле persistence содержатся "функции которые ходят в базу", (от себя добавлю - их тестирование тривиально т.к. это паттерн "репозиторий" - просто вытащить и передать в нужной структуре наверх).
Так, наверно понял о чём Вы. В том плане что разные подходы: мы полностью что-то меняем, вместо того что бы расширять? Ну дак вроде не противоречит. Мы же не отвёрткой в существующем ковыряемся что бы что-то подправить (вот если бы мы что-то добавляли "сбоку", опираясь на элементы конструкции готового узла - наверно это как раз было бы расширением).
Да и вообще "принцип узлов, агрегатов" не сформулирован тут, а искать лень, не моё направление. Надеялся @DenisPantushev пояснит в двух словах.
Я так понял что @DenisPantushev имеет в виду что как минимум один из принципов SOLID нарушает подход к проектированию системы как к набору узлов-агрегатов.
Извините, а чем SOLID нарушает "этот" принцип? И какой "этот" - сборки конструкции из узлов? Вроде наоборот, там про границы между компонентами в основном всё.
Стили изложения - отличный. Спасибо за статью. Добавил в закладки, позже попробую полностью осмыслить.
Я правильно понимаю что Вы предлагаете успешно делаете такое: вместо размазывания БЛ по сервисам с невнятной категоризацией (или без неё вообще как на примере с 50тью кейзами) помещать её в методы БЛ объектов(entity)? И что бы БЛ из объектов не лезла во всякие там репозитории - методы возвращают объекты-команды "обновляторы", которые уже и будут применять обновление в БД через репозиторий? Ну т.е. это один из посылов статьи, так? Я только недавно встал на путь "чистого кода", хехе, вопрос наверно наивный, пока для себя расставляю по полкам всё.
Да, и разве SOLID Мартина заставляет гранулировать? В том смысле у него есть понятия скромного объекта, но оно для вещей которые сложно тестировать (типа отрисовки в UI). А вот в какой момент вдруг все БЛ-сущности предлагается хранить отдельно в виде DTO а логику в отдельном месте я вот не помню, но вроде не у Мартина. Перечитаю. Хотя я скорее всего не до конца понял Ваш замысел, так что наверно вопрос глупый, надо перечитать основательно и в сам кукбук поглядеть.
И да, кстати, спасибо за ссылку на ROP, прочистило мозги.
Да ладно! А я заржал в голос. Смешно же. Это же специально на первом месте, что бы дальше люди не загонялись а поняли что это шутка, транспарант, так сказать.
Странные претензии)) Автор написал то что посчитал нужным. Откуда такие требования? Вопрос о принципиальном различии (с точки зрения автора) - раскрыт (это уже с моей точки зрения). Вы почему-то ожидали каких-то там примеров, подробных сравнений для разных решений, конкретных областей применения(!), почему? Откуда такие ожидания? Кто их Вам обещал и не выполнил?
Со сложностью - может и так, но это субъективное. Кто-то начинающий, а кто-то (представьте себе) - нет.
Смешно получается, парадокс некий. RelationDB (relation - отношения) - на самом деле без отношений. Ну т.е. если запись (строку в таблице) интерпретировать как объект - то да, безусловно поля относятся к одной сущности. А вот если мыслить уже сущностями как атомарными единицами то внезапно Relation БД уже без связей между этими сущностями.
Не не, тут похоже дело в том что встроенная карточка работает на основной оперативке и перегон из "видеопамяти" в основную - мгновенный. Похожий эффект наблюдал при захвате, на ноуте летало а на большом брате как-то не очень.
У меня сложилось ощущение что весь их спор - из-за разного подхода к необходимости написания тестов. Мартин изначально пишет под тесты, его подход так и выглядит - много мелких объектов/функций.
PS: больше спасибо за перевод.
А главное - газовая труба со счетчиком на дальней стене! С ними что-то сделать - это же боль. Нет, это БОЛЬ. А тут рррраз - и нет труб) AI - сила!
Впрочем, это явно кухня а дизайн под гостиную, наверно неудачный пример помещения.
Иначе, где гарнитур-то? Видимо справа за углом пара модулей на 60) Чисто руки помыть и винишко открыть, а еду можно и в ресторанах заказать (вот это жена точно одобрит)
Спасибо за ссылки в конце статьи, нашел для себя пару интересных.
Про точки, тире, пробелы - для меня прям откровение. С точками так смешно: всегда подозревал что есть какой-то правильный красивый подход но никак не мог заняться поиском, да даже проблему не мог сформулировать для себя, вижу что "не айс", а что понять не мог.
Спасибо!
Отличные, кстати. Обе две.
Спринты есть, если что. Задачи можно доской можно кантом смотреть. Иерархия вложенными задачами делается. Это так, на вскидку. По остальному не скажу. Trello - бледная копия по сравнению с, так-то.
года два, а то и три, точно не скажу
Yougile не смотрели? Хорошая. Платная, если что, не реклама, сидим на ней, довольны.
Подписываюсь под каждой буквой.
Ну вы статью прочтите хоть. Там в разделе "Микросервисы" приведена структура приложения. Только в модуле
persistenceсодержатся "функции которые ходят в базу", (от себя добавлю - их тестирование тривиально т.к. это паттерн "репозиторий" - просто вытащить и передать в нужной структуре наверх).Так, наверно понял о чём Вы. В том плане что разные подходы: мы полностью что-то меняем, вместо того что бы расширять? Ну дак вроде не противоречит. Мы же не отвёрткой в существующем ковыряемся что бы что-то подправить (вот если бы мы что-то добавляли "сбоку", опираясь на элементы конструкции готового узла - наверно это как раз было бы расширением).
Да и вообще "принцип узлов, агрегатов" не сформулирован тут, а искать лень, не моё направление. Надеялся @DenisPantushev пояснит в двух словах.
Open-Closed это буква О в SOLID
Я так понял что @DenisPantushev имеет в виду что как минимум один из принципов SOLID нарушает подход к проектированию системы как к набору узлов-агрегатов.
Жутко интересно, какой именно.
Извините, а чем SOLID нарушает "этот" принцип? И какой "этот" - сборки конструкции из узлов? Вроде наоборот, там про границы между компонентами в основном всё.
Стили изложения - отличный. Спасибо за статью. Добавил в закладки, позже попробую полностью осмыслить.
Я правильно понимаю что Вы
предлагаетеуспешно делаете такое: вместо размазывания БЛ по сервисам с невнятной категоризацией (или без неё вообще как на примере с 50тью кейзами) помещать её в методы БЛ объектов(entity)? И что бы БЛ из объектов не лезла во всякие там репозитории - методы возвращают объекты-команды "обновляторы", которые уже и будут применять обновление в БД через репозиторий? Ну т.е. это один из посылов статьи, так? Я только недавно встал на путь "чистого кода", хехе, вопрос наверно наивный, пока для себя расставляю по полкам всё.Да, и разве SOLID Мартина заставляет гранулировать? В том смысле у него есть понятия скромного объекта, но оно для вещей которые сложно тестировать (типа отрисовки в UI). А вот в какой момент вдруг все БЛ-сущности предлагается хранить отдельно в виде DTO а логику в отдельном месте я вот не помню, но вроде не у Мартина. Перечитаю. Хотя я скорее всего не до конца понял Ваш замысел, так что наверно вопрос глупый, надо перечитать основательно и в сам кукбук поглядеть.
И да, кстати, спасибо за ссылку на ROP, прочистило мозги.
Спасибо за статью. Коллеги, дак а что на счёт юнит-тестов? Как для них удобней будет, относительный таки? Как это правильно делать?
Да ладно! А я заржал в голос. Смешно же. Это же специально на первом месте, что бы дальше люди не загонялись а поняли что это шутка, транспарант, так сказать.
Странные претензии)) Автор написал то что посчитал нужным. Откуда такие требования? Вопрос о принципиальном различии (с точки зрения автора) - раскрыт (это уже с моей точки зрения). Вы почему-то ожидали каких-то там примеров, подробных сравнений для разных решений, конкретных областей применения(!), почему? Откуда такие ожидания? Кто их Вам обещал и не выполнил?
Со сложностью - может и так, но это субъективное. Кто-то начинающий, а кто-то (представьте себе) - нет.
Смешно получается, парадокс некий. RelationDB (relation - отношения) - на самом деле без отношений. Ну т.е. если запись (строку в таблице) интерпретировать как объект - то да, безусловно поля относятся к одной сущности. А вот если мыслить уже сущностями как атомарными единицами то внезапно Relation БД уже без связей между этими сущностями.
>И деалют они это скорее всего точно также как реляционные
Нет.
Не не, тут похоже дело в том что встроенная карточка работает на основной оперативке и перегон из "видеопамяти" в основную - мгновенный. Похожий эффект наблюдал при захвате, на ноуте летало а на большом брате как-то не очень.