Набор инструментов NSwag - это всё же как раз .NET. Octopus тоже известен скорее в .NET-кругах. А так да, практики универсальные, хоть и выстраданы на .NET-проектах :)
У меня несколько лет были боли в спине и не только в спине. По ДМС было сделано несчетное количество походов к неврологу, исследований типа МРТ (разумеется нашли протрузии, куда без них), курсов лекарств и процедур. А в итоге проблема решилась психотерапией с антидепрессантами. Такие дела. Впрочем хорошее кресло я тоже купил, но это другая история.
Я бы сказал, что эксклюзивную информацию можно получить, пообщавшись со спикером после доклада. На зал и тем более на камеру можно сказать не всё, но в частном разговоре все обычно более откровенны.
Времени действительно требуется немало, если говорить о подготовке доклада. Но и эффект получается совсем другой, чем ехать простым участником. Например, можно случайно познакомиться с amorev :)
1. Про уровень связности: я отталкиваюсь от текущей обстановки. Если начинаю чувствовать, что дальнейшее упорство в разделении зависимостей становится слишком дорогим, то останавливаюсь. Естественно, что со временем появляется интуитивное чувство, которое сразу говорит, когда хватит. В каких единицах измерить уровень связности, я не знаю, поэтому количественно затрудняюсь ответить.
2. Про разнесение интерфейсов по слоям: тут важно понимать, где начало графа, а где конец. И, соответственно, кто (какой слой) диктует изменения, а кто подстраивается. Если интерфейс в доменном слое, а реализация в инфраструктуре, то от изменения инфраструктуры интерфейс в домене меняться не должен. Потому что он описывает доменную логику, причина для изменения которой — бизнес-процессы. Понятно, что в реальном мире бывает по-другому (например, были все методы синхронными, а стали асинхронными), тогда да, придется по всей вертикали проводить изменения.
3. Про примеры. На самом деле есть ровно один способ посмотреть на серьезный большой проект: пойти работать на такой проект. Вариант немного хуже — читать книги. Книжный объем уже позволяет обрисовать довольно масштабную картину, хотя до реального проекта все равно будет далеко. Еще как вариант мастер-классы от мэтров типа тех же авторов книг. В интернетах нормальных примеров я не встречал. Там обычно загоняются на тактические паттерны, но без реальной предметной области и соответствующих процессов они не имеют смысла (с точки зрения ддд). С опен-сорсом (а точнее с крауд-сорсом, вы же это имеете в виду, да?) та же проблема: нету тех самых бизнес-задач и бизнес-процессов, от которых отталкивается разработка в коммерческих проектах.
Я, кстати, выяснил, когда готовил примеры к докладу, что решарпер (кажется это он, а не студия) умеет автоматически распознавать комбинации с ключевыми словами, независимо от раскладки. То есть пишете «зкшмфеу», а оно само превращается в private.
и начинаются разговоры “А почему вы запрещаете использовать мне var’ы? У меня же такой хороший код, ни одного типа не видно, и всё как должно быть в функциональном программировании”
То есть в то время, как c# вместе со всем прогрессивным миром движется в сторону функционального подхода, вы учите студентов не использовать var?
Да, конечно. В данном случае подпись проверялась ещё до адаптера. А адаптер нужен был уже на этапе работы с бизнес-логикой.
Набор инструментов NSwag - это всё же как раз .NET. Octopus тоже известен скорее в .NET-кругах. А так да, практики универсальные, хоть и выстраданы на .NET-проектах :)
Не секрет) КПТ
У меня несколько лет были боли в спине и не только в спине. По ДМС было сделано несчетное количество походов к неврологу, исследований типа МРТ (разумеется нашли протрузии, куда без них), курсов лекарств и процедур. А в итоге проблема решилась психотерапией с антидепрессантами. Такие дела. Впрочем хорошее кресло я тоже купил, но это другая история.
Отлично! Заглядывайте к нам на стенд, подарим что-нибудь за решительность :)
Времени действительно требуется немало, если говорить о подготовке доклада. Но и эффект получается совсем другой, чем ехать простым участником. Например, можно случайно познакомиться с amorev :)
Ну он и не скрывает, что vb — его любимый язык. В первой части прямо так и написал.
2. Про разнесение интерфейсов по слоям: тут важно понимать, где начало графа, а где конец. И, соответственно, кто (какой слой) диктует изменения, а кто подстраивается. Если интерфейс в доменном слое, а реализация в инфраструктуре, то от изменения инфраструктуры интерфейс в домене меняться не должен. Потому что он описывает доменную логику, причина для изменения которой — бизнес-процессы. Понятно, что в реальном мире бывает по-другому (например, были все методы синхронными, а стали асинхронными), тогда да, придется по всей вертикали проводить изменения.
3. Про примеры. На самом деле есть ровно один способ посмотреть на серьезный большой проект: пойти работать на такой проект. Вариант немного хуже — читать книги. Книжный объем уже позволяет обрисовать довольно масштабную картину, хотя до реального проекта все равно будет далеко. Еще как вариант мастер-классы от мэтров типа тех же авторов книг. В интернетах нормальных примеров я не встречал. Там обычно загоняются на тактические паттерны, но без реальной предметной области и соответствующих процессов они не имеют смысла (с точки зрения ддд). С опен-сорсом (а точнее с крауд-сорсом, вы же это имеете в виду, да?) та же проблема: нету тех самых бизнес-задач и бизнес-процессов, от которых отталкивается разработка в коммерческих проектах.
nmivan, перелогиньтесь
То есть в то время, как c# вместе со всем прогрессивным миром движется в сторону функционального подхода, вы учите студентов не использовать var?
2009 — я второй раз в жизни писал на .Net, это было winforms-приложение для диссертации.
2019 — я в топ10 докладов DotNext Moscow.
— Да, не спорю.
— Но так же не бывает!
— Да, не бывает.
Что-то шаг мелковат. Да и прибавлять лучше в процентах, скажем процентов 20.