> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
Так я и говорю о том, что на Ваших иллюстрациях ни луковая, ни гексагональная архитектура. Так что эти иллюстрации подходят для дизайна, но не подходят для архитектуры.
Примеры тоже все про разделение ответственности по классам, а значит -- про дизайн.
CQRS я просто вспомнил как ещё один пример архитектуры с разделением мутабельности/иммутабельности, к теме статьи это никак не относится.
Хотелось бы уточнить, что сам я за такой подход – разделение мутабельного и иммутабельного кода – всеми руками и ногами, что у меня есть :), просто мы с Вами расходимся во мнении, где кончается архитектура и начинается дизайн. Предлагаю на этом закончить и разойтись, каждый со своим мнением :).
Если мы говорим за архитектуру, в которой иммутабельное ядро (обычно это домен) оборачивается в мутабельную оболочку (оболочки), то тогда это луковичная (onion) или гексагональная архитектуры, и слоёв там больше чем два. Приведённые же иллюстрации (те, на которых круги) как раз таки очень хорошо подходят для концепции широкого и глубокого кода, которая про дизайн.
К слову, ещё один вариант архитектуры с разделением на мутабельные и иммутабельные части – CQRS, только там они не оборачивают друг друга, а существуют параллельно.
Только непонятно, почему автор использует термин "архитектура". Раз мы оперируем классами, то речь идёт об иммутабельном дизайне. Архитектура лежит выше и даже не знает, что там внизу - ООП, ФП или процедурщина.
Не понял про версии тестов. Я про то, что тесты лежат совсем отдельно от основного кода, в отдельном проекте. Стек .NET.
Почему отсутствие документации на код сразу делает его говнокодом? Слишком сильное утверждение.
Мы вот, например, стараемся писать самодокументируемый код. Вполне себе не говнокод получается, но отдельного файла с документацией рядом с кодом нет.
Да и вообще я такого никогда не видел.
Спасибо, но не надо.
При разбиении по принципу per layer проще контролировать сохранность архитектуры – репозитории (DAL-уровень) находятся в своём проекте, сервисы (BLL) – в своём, контроллеры (PL) – в своём. Отсутствие протечек можно контролировать на код-ревью (например, через namespaces), можно и архитектурные тесты написать (ищите выступления Дениса Цветциха).
Если файлы из разных архитектурных слоёв будут свалены в одну папку, то уровни не то что протекут – всё просто хлынет. Гарантировано.
А вот в рамках одного уровня (например, бизнес-логики) можно и по принципу per feature всё складывать, здесь проблем не вижу.
Забавно – как раз сейчас читаю предыдущую инкарнацию этой книги (Прайс — C# 7 и .NET Core. Кросс-платформенная разработка для профессионалов) и как раз сегодня с утра читал эту главу =D.
Бывают же совпадения )))
> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
Там надо щёлкнуть по шкале и выставить ноль. Тогда ответ принимается.
// зануда on
2500 тысяч == 2,5 млн.
// зануда off
:)
Влад, супер! И идея, и реализация.
Единственное, чего не достаёт до идеала – настройки размера шрифта не только в редакторе, но и в output.
P.S. Мне ещё хоткеев не хватает, но это уже капризы )))
Ищу и качаю в свободное от чтения время =D. Накопилось уже 67 гигов книг (и это только по IT).
Каждый рабочий день утром, после подъема, полчаса читаю книги. На одну книгу примерно месяц уходит, в год по 10-12 штук.
Женат + дети, не трезвенник, друзья есть. Воля вот ни разу не стальная. ЧЯДНТ?
Попробовал войти несколько раз, с паузами в несколько часов. Каждый раз ошибка с капчой :(.
Книга шикарна. Крайне всем рекомендую, особенно мне зашла концепция широкого и глубокого кода.
Владимир, спасибо!
P.S. Но всё равно я адепт лондонской школы =D.
Так я и говорю о том, что на Ваших иллюстрациях ни луковая, ни гексагональная архитектура. Так что эти иллюстрации подходят для дизайна, но не подходят для архитектуры.
Примеры тоже все про разделение ответственности по классам, а значит -- про дизайн.
CQRS я просто вспомнил как ещё один пример архитектуры с разделением мутабельности/иммутабельности, к теме статьи это никак не относится.
Хотелось бы уточнить, что сам я за такой подход – разделение мутабельного и иммутабельного кода – всеми руками и ногами, что у меня есть :), просто мы с Вами расходимся во мнении, где кончается архитектура и начинается дизайн. Предлагаю на этом закончить и разойтись, каждый со своим мнением :).
А вот теперь я с Вами не соглашусь :)
Если мы говорим за архитектуру, в которой иммутабельное ядро (обычно это домен) оборачивается в мутабельную оболочку (оболочки), то тогда это луковичная (onion) или гексагональная архитектуры, и слоёв там больше чем два. Приведённые же иллюстрации (те, на которых круги) как раз таки очень хорошо подходят для концепции широкого и глубокого кода, которая про дизайн.
К слову, ещё один вариант архитектуры с разделением на мутабельные и иммутабельные части – CQRS, только там они не оборачивают друг друга, а существуют параллельно.
Только непонятно, почему автор использует термин "архитектура". Раз мы оперируем классами, то речь идёт об иммутабельном дизайне. Архитектура лежит выше и даже не знает, что там внизу - ООП, ФП или процедурщина.
Для описанного в статье подхода Хориков в своей книге использует термины "широкий и глубокий код".
Вообще-то американский MM-DD-YYYY, Ваш пример выглядит в нём как "12-24-2020". А это формат ISO-8601.
Всплакнул...
Мы вот, например, стараемся писать самодокументируемый код. Вполне себе не говнокод получается, но отдельного файла с документацией рядом с кодом нет.
Да и вообще я такого никогда не видел.
Спасибо, но не надо.
При разбиении по принципу per layer проще контролировать сохранность архитектуры – репозитории (DAL-уровень) находятся в своём проекте, сервисы (BLL) – в своём, контроллеры (PL) – в своём. Отсутствие протечек можно контролировать на код-ревью (например, через namespaces), можно и архитектурные тесты написать (ищите выступления Дениса Цветциха).
Если файлы из разных архитектурных слоёв будут свалены в одну папку, то уровни не то что протекут – всё просто хлынет. Гарантировано.
А вот в рамках одного уровня (например, бизнес-логики) можно и по принципу per feature всё складывать, здесь проблем не вижу.
Будет, ибо:
Хаб "ASP" видимо по ошибке указан.
Будет ли совместима по расширениям с VS2019? Или опять полгода ждать, пока авторы расширений перепишут их под новую студию?
Забавно – как раз сейчас читаю предыдущую инкарнацию этой книги (Прайс — C# 7 и .NET Core. Кросс-платформенная разработка для профессионалов) и как раз сегодня с утра читал эту главу =D.
Бывают же совпадения )))