Я очень люблю задавать вопрос про SOLID на собеседованиях, не потому что жду четкого и верного ответа, а потому что мне интересно как человек понимает принципы. Даже по комментариям здесь видно что сколько людей - столько трактовок и мнений :) А из трактовки и понимания уже легко понять опыт человека, и проблемы, с которыми он сталкивался.
Мне кажется часто "сложно делать" у разработчиков напрямую отображает сложность и неизведанность проблемы у бизнеса. "Удалить пользователя из CRM" или "атомарно подписать многостраничный договор" это простой (наивный?) взгляд на действительно сложные "бизнесовые" проблемы. Ведь никто в реальном не мире заполняет и принимает договора в один присест. В реальности сотрудник днями бегает с договором по департаментам, согласует отдельные части, черкает черновики, делает записи на липких бумажках и пометки в блокнотик, и даже заполняет документ с конца, потому что какие-то данные знает заранее.
Спасибо за статью! Работаю с ДДД и крупными проектами, но масштаб описанный в статье почти никогда не встречал. Отсюда у меня вытекает вопрос, насколько рационально натягивать рекомендации и правила из ДДД на такие сложные операции.
Условно, если у бизнеса требование, что нажатие на красную кнопку создает 100 новых записей (в разных таблицах), считает 10 годовых отчетов, отправляет результаты на почту начальству и еще деньги переводит сразу всем подрядчикам, то тут, прежде чем пинать на опасность саг и думать на какие bound contexts это все разделить, я бы сначала подумал как вообще тут обеспечить надежность и согласованость всего этого. Ну и поговорил бы с бизнесом о рисках и проблемах с такими "жирными" операциями, и возможным разделением их на части (например две синих кнопки, вместо одной красной).
Если ваша бизнес-логика зависит от RxJS (или, например, MediatR, Rx.NET), то у вас, скорее всего, проблемы с архитектурой приложения. Простыми словами - ваших БА интересует какая там версия у Rx.NET новая вышла и надо ли ее обновить, или стори они пишут под RxJS “BehaviorSubject ‘user’ should return current user”? Зависимости на инфраструктуру для бизнес-слоя нужно разворачивать через интерфейсы, чтобы инфраструктура имплементила domain интерфейсы.
Ой-ёй. Диаграмма направления зависимостей неверная. Бизнес логика и UI компоненты не могут зависеть от инфраструктуры. Слой инфраструктуры должен распологаться на одном уровне с UI компонентами.
По теме - единый доменный язык это, наверное, главное что нужно брать из DDD. Остальное - детали имплементации.
На цену влияет много факторов. Маленькие партии на производствах стоят очень дорого. Дотошный контроль качества, отсекающий до трети готовой партии. Экзотичные материалы и «технологии», которые не всегда свободно доступны. И это только на этапе производства.
Упс, посчитал кроме кузова ещё и остальные компоненты. Даже если не брать KeyCult, ~800$ это не редкая цена в групбаях. Плюс налоги если фабрики/вендоры не в Европе (я сам в Европе).
Rama клавиатуры это не hi-end, это такой среднечковый конвейер кастома, но ещё не mass-market. Неплохой вариант для любителей кастома, но и коллекционным не является.
Суть и стоимость кастомных клавиатур описывается «законом убывающей доходности» (diminishing returns). В целом схожий принцип с дорогими машинами, часами и аудиотехникой. Ну а более подробно «что именно там такое дорогое и почему» тянет на отдельную статью.
P.S. Разбираюсь в теме, имею в коллекции 14 кастомных клавиатур, стоимостью до 1500$ (себестоимость, не рыночная)
Спасибо, очень интересная статья! Сколько себя помню, в семье всегда все страдали от нейродермита. Для себя выяснил что мази с пантенолом помогают лучше всего, поэтому всегда дома, в машине и на работе имеется по тюбику. Единственное, во время обострения и по 4 раза в сутки мазать недостаточно. Уже заказываю ваш гель, посмотрим как он себя покажет.
Приятно видеть как любимое хобби становится все популярнее и популярнее в широких массах. Вот уже и статьи на хабре зачастили. Спасибо за отличную, подробную статью!
Хабр Коллаб (ХабраКоллабра?) для поиска единомышленников для open-source и пет-проектов. Для рекламы своих собственных разработок и репозиторий. На хабре много статей пишутся как раз с такой целью, так почему бы не формализировать это в новом сервисе?
Наболело
Как раз столкнулся с такой проблемой. Написал библиотечку, успешно использую в своих целях, а как продвигать дальше и где получить отзывы — не знаю. На полноценную хабра-статью не тянет :(
Потенциально можно двигаться в сторону it-инкубатора (на подобие y-combinator), ну и вообще всячески продвигать идейную разработку. Это могут быть хакатоны, конференции, митапы, и т.д.
Полностью согласен с тем, что если не хочешь быть обманутым — нужно хотя бы минимально разбираться. Про поломки и особенности своего автомобиля стараюсь читать. Чинить что-то, конечно, не полезу, но в сервисе объясниться и уточнить детали смогу.
Ради интереса, а какие поломки в автомобиле вы можете починить «в поле», без подготовки и имея только стандартный набор инструментов? Ну кроме установки запаски и замены ремня ГРМ? Например я сталкивался с такими проблемами как обрыв троса сцепления и поломки топливного насоса. Вы и это можете починить в дороге?
ИМХО умение детей готовить и выполнять работу по дому зависит от воспитания, а не от среды проживания.
Умение обращаться с инструментами, животными, растениями и грибами я не считаю необходимым для выживания. Ремонт чего угодно — быстро, профессионально и в любой точке города. Обращение с животными — бесполезно, я по городу на велосипеде езжу, а не на лошади. В супермаркетах и на рынках только съедобные грибы и ягоды. Если не уверен — продавец подскажет.
Простите, но у меня личная неприязнь к аргументу «Не умеешь обращаться с инструментами — не приспособлен к жизни». Очень часто слышу его когда в очередной раз отвожу машину на сервис чтобы заменить тормозные колодки или исправить какой-нибудь другой пустяк. Мне не интересно копаться в машине, точно так-же как собирать грибы (я их просто не ем), или ездить на лошади.
Иногда мне кажется, что люди хватаются за любой повод выделиться и потешить свое самолюбие, пусть даже этот повод и очень мизерный.
Речь идет не о том, что бы есть некачественные плоды, а о том, что бы использовать землю и посадки для выращивания качественных (годных в пищу людям). То, что для человека все равно не годится, используется для компостирования.
Для производства растительной пищи нужны удобрения из тел животных
Опять же, нет, удобрения из «тел животных» дешевле и более распространены, но не абсолютно необходимы. Компост вполне может являться источником нужных удобрений для почвы. В том числе и источником азота, благодаря азотфиксирующим бактериям.
Аргумент про Аллана Сейвори я не понял, ведь он как раз подтверждает мою точку зрения. Конечная цель Аллана это использование опустыненой территории в земледелии, а не в качестве постоянного пастбища, так что «производство мяса» в его случае это лишь промежуточный эффект производства растительной пищи.
Растениям нужен не навоз, а удобрения. Отличные альтернативы навозу это компост и минеральные удобрения. Кстати всего 5% посадок в Америке удобряются навозом. Я считаю что вы преувеличиваете роль навоза.
Мы вам перезвоним
Я очень люблю задавать вопрос про SOLID на собеседованиях, не потому что жду четкого и верного ответа, а потому что мне интересно как человек понимает принципы. Даже по комментариям здесь видно что сколько людей - столько трактовок и мнений :) А из трактовки и понимания уже легко понять опыт человека, и проблемы, с которыми он сталкивался.
Спасибо, понял. Есть над чем задуматься.
Мне кажется часто "сложно делать" у разработчиков напрямую отображает сложность и неизведанность проблемы у бизнеса. "Удалить пользователя из CRM" или "атомарно подписать многостраничный договор" это простой (наивный?) взгляд на действительно сложные "бизнесовые" проблемы. Ведь никто в реальном не мире заполняет и принимает договора в один присест. В реальности сотрудник днями бегает с договором по департаментам, согласует отдельные части, черкает черновики, делает записи на липких бумажках и пометки в блокнотик, и даже заполняет документ с конца, потому что какие-то данные знает заранее.
Спасибо за статью! Работаю с ДДД и крупными проектами, но масштаб описанный в статье почти никогда не встречал. Отсюда у меня вытекает вопрос, насколько рационально натягивать рекомендации и правила из ДДД на такие сложные операции.
Условно, если у бизнеса требование, что нажатие на красную кнопку создает 100 новых записей (в разных таблицах), считает 10 годовых отчетов, отправляет результаты на почту начальству и еще деньги переводит сразу всем подрядчикам, то тут, прежде чем пинать на опасность саг и думать на какие bound contexts это все разделить, я бы сначала подумал как вообще тут обеспечить надежность и согласованость всего этого. Ну и поговорил бы с бизнесом о рисках и проблемах с такими "жирными" операциями, и возможным разделением их на части (например две синих кнопки, вместо одной красной).
Если ваша бизнес-логика зависит от RxJS (или, например, MediatR, Rx.NET), то у вас, скорее всего, проблемы с архитектурой приложения. Простыми словами - ваших БА интересует какая там версия у Rx.NET новая вышла и надо ли ее обновить, или стори они пишут под RxJS “BehaviorSubject ‘user’ should return current user”? Зависимости на инфраструктуру для бизнес-слоя нужно разворачивать через интерфейсы, чтобы инфраструктура имплементила domain интерфейсы.
Ой-ёй. Диаграмма направления зависимостей неверная. Бизнес логика и UI компоненты не могут зависеть от инфраструктуры. Слой инфраструктуры должен распологаться на одном уровне с UI компонентами.
По теме - единый доменный язык это, наверное, главное что нужно брать из DDD. Остальное - детали имплементации.
На цену влияет много факторов. Маленькие партии на производствах стоят очень дорого. Дотошный контроль качества, отсекающий до трети готовой партии. Экзотичные материалы и «технологии», которые не всегда свободно доступны. И это только на этапе производства.
Упс, посчитал кроме кузова ещё и остальные компоненты. Даже если не брать KeyCult, ~800$ это не редкая цена в групбаях. Плюс налоги если фабрики/вендоры не в Европе (я сам в Европе).
Rama клавиатуры это не hi-end, это такой среднечковый конвейер кастома, но ещё не mass-market. Неплохой вариант для любителей кастома, но и коллекционным не является.
Суть и стоимость кастомных клавиатур описывается «законом убывающей доходности» (diminishing returns). В целом схожий принцип с дорогими машинами, часами и аудиотехникой. Ну а более подробно «что именно там такое дорогое и почему» тянет на отдельную статью.
P.S. Разбираюсь в теме, имею в коллекции 14 кастомных клавиатур, стоимостью до 1500$ (себестоимость, не рыночная)
Потенциально можно двигаться в сторону it-инкубатора (на подобие y-combinator), ну и вообще всячески продвигать идейную разработку. Это могут быть хакатоны, конференции, митапы, и т.д.
Полностью согласен с тем, что если не хочешь быть обманутым — нужно хотя бы минимально разбираться. Про поломки и особенности своего автомобиля стараюсь читать. Чинить что-то, конечно, не полезу, но в сервисе объясниться и уточнить детали смогу.
Умение обращаться с инструментами, животными, растениями и грибами я не считаю необходимым для выживания. Ремонт чего угодно — быстро, профессионально и в любой точке города. Обращение с животными — бесполезно, я по городу на велосипеде езжу, а не на лошади. В супермаркетах и на рынках только съедобные грибы и ягоды. Если не уверен — продавец подскажет.
Простите, но у меня личная неприязнь к аргументу «Не умеешь обращаться с инструментами — не приспособлен к жизни». Очень часто слышу его когда в очередной раз отвожу машину на сервис чтобы заменить тормозные колодки или исправить какой-нибудь другой пустяк. Мне не интересно копаться в машине, точно так-же как собирать грибы (я их просто не ем), или ездить на лошади.
Иногда мне кажется, что люди хватаются за любой повод выделиться и потешить свое самолюбие, пусть даже этот повод и очень мизерный.
Опять же, нет, удобрения из «тел животных» дешевле и более распространены, но не абсолютно необходимы. Компост вполне может являться источником нужных удобрений для почвы. В том числе и источником азота, благодаря азотфиксирующим бактериям.
Так же может быть оправданным использование «человеческого навоза»
Аргумент про Аллана Сейвори я не понял, ведь он как раз подтверждает мою точку зрения. Конечная цель Аллана это использование опустыненой территории в земледелии, а не в качестве постоянного пастбища, так что «производство мяса» в его случае это лишь промежуточный эффект производства растительной пищи.