Comments 26
Заглавная картинка в виде кода на черном фоне вам досталась по наследству от fillpackart? Он как раз поменял оформление статей.
Ну просто очень уж бросается в глаза стилистика оформления статьи. Не, может это только мне так кажется. Но прям бросается в глаза.
В конце статьи я прямо выражаю благодарность fillpackart и его сообществу за помощь с редактурой и оформлением. Идею картинок с кодом в качестве иллюстраций я тоже украл у него. Только он любит Rider, а я — Visual Studio
Это кринж :) Он делается чтобы было стыдно читателю.
Странно, почему мне должно быть стыдно за то, что написали вы? Мне, например, всё равно, как вы напишите — "интерпрайз", "энтерпрайз" или "enterprise". На какой круг читателей должен воздействовать этот ваш кринж, если не секрет?
Не секрет: это должно воздействовать на круг чрезмерно серьёзных читателей, которые потребуют от меня маркетингового буклета про мой фреймворк, сравнительного анализа подходов, метрик, планов по интеграции в существующие приложения, примеры success story на живых проектах и сильно разочаруются, когда узнают что всего этого пока ещё нет.
Разработка сейчас медленно перекатывается из стадии "proof of concept" на стадию "early adopters" и вкладываться в вышеперечисленные вещи ещё не время.
Заголовок с намеренными терминологическим кринжем сразу снижает градус серьёзности обсуждения, оставляя внимание только концептуально заинтересованных людей, которым интересно посмотреть на эксперимент (например, вас). На данный момент мне приоритетно работать именно с ними. Защищаться от нападок в жанре "а где примеры реального использования?!!" я пока не готов и не хочу тратить ни своё ни чужое время на это.
Как-то так. Извините, если грубовато.
Один коммент по оформлению — гифки выглядят очень наглядно но их нельзя поставить на паузу. Можете ниже прятатать под спойлером скрин с финальным вариантом?
По задумке, обслуживать это дело должен системный архитектор. Я полагаю, в любой компании найдётся бородатый разработчик, который сможет один раз в этом разобраться, настроить и больше никогда не трогать.
Как бы не получилась такая ситуация — бизнесс-логику стало просто писать, хватит одного мидла, но ему нужны готовые аспекты и каналы. А их пишет только вон тот опытный бородач. И не успевает. Надо два таких, нет, лучше три. А то тут кровавый интерпраиз и новая система для интеграции, снова.
Вы ведь сами признаете проблематику:
Работа с внешними системами — это краеугольный камень разработки бизнес-приложений… Откройте свой рабочий проект, найдите то, что у вас называется «бизнес-логика»: это просто код, который сам ничего не делает, а только говорит что делать внешним по отношению к вашей системам. Какие-то действительно сложные вычисления руками в рамках формошлёпства — скорее исключение, чем правило.
Бородачу наверно не интересно писать одни аспекты. Компании неинтересно нанимать кучу бородачей за большие деньги, но выбора нет, мидлы написание аспектов не потянут. Или потянут?
Вообщем, это хотелось бы понять из вашего эксперимента:
Сейчас мне на работе выделили небольшой кусок системы, чтобы обкатать Tecture. Не хочу говорить ничего раньше времени, но по результатам будет обзорная статья.
Вы ведь не в одиночку будете это обкатывать?
А их пишет только вон тот опытный бородач
Я всё делаю из предположения что логики у вас будет в любом случае больше, чем каналов и аспектов, так что на практике эта ситуации видится мне зело маловероятной.
Или потянут?
Я сделаю всё от меня зависящее чтобы потянули. Сейчас немного разгребусь с текучкой и напишу детальные пошаговые инструкции-чеклисты по написанию аспектов и рантаймов. Мне сложно оценить сложность такой задачи — как по мне она довольно лёгкая и творческая. Плюс аспекты вполне могут кочевать из проекта в проект — почему нет?
В общем, мне сложно представить как именно это будет работать вживую, но вроде проблем быть не должно — структура система всё ещё разборная, а значит базовая гибкость будет.
Вы ведь не в одиночку будете это обкатывать?
С коллегой :)
Автогенерация тестов тоже порадовала. Это прямо решает всю боль разрабов. Интересен, конечно, момент — насколько они получаются полные? Насколько покрывают корнер кейсы, особенно в случае с ветвистой логикой поведения из условных операторов? Такой код, конечно, «некрасивый» и «неправильный» — но будем реалистами — в энтерпрайсе он появится в любом случае.
Спасибо за отзыв.
Трэйс прямо божественен
В имейте в виду только что в него попадают все действия с каналами. То есть совсем все. Будет у вас кэш — факт записи в него тоже свалится в трейс. Хотя в целом трейс вполне можно отфильтровать руками и сделать свой Explain, включив туда только то, что интересно.
Насколько покрывают корнер кейсы
То, что я делаю называется data-driven testing или table-driven testing. Такие тесты не покрывают совершенно все corner case-ы — вы должны сделать это сами, но в смысле не руками, а подбить правильные тестовые данные и вводные, чтобы у вас проверялись все ветки. Ну то есть условно регистрируйте в своей админке юзера с одними правами — пробуете из теста залогиниться и удалить файл, захватываете занные. Заводите юзера с другими правами — пробуете то же самое ещё раз, захватываете данные.
На реальных проектах вам наверняка с этим поможет QA. То есть корнер-кейсы за вас не откроют, но уже открытые помогут оформить.
идеальный стэйктрейс вызова
Ну всё же не стоит использовать его как стектрейс — он тяжеловат будет в рантайме. Трейс — штука чисто на этапе разработки и дебага. Но я подумаю над тем, чтобы сделать облегченную версию. Слишком уж мне нравится, как этот автор пишет :)
Ну и может быть «хэштэги», типа возможность добавить список тэгов, что позволит при анализе описаний делать какой-никакой фильтр.
Меня немного напрягает, что BeginTrace и EndTrace надо вызывать руками, очень легко один из этих вызовов забыть. Вы не думали сделать отдельный тип, который при создании вызывает BeginTrace и в Dispose вызывает EndTrace, чтобы трейс можно было использовать с оператором using и таким образом исключить возможность забыть вызвать EndTrace?
Я думал о том, чтобы добавить такую опцию, но забегался и забыл. Сделать такую обёртку нетрудно руками.
Но это в любом случае opt-in, потому что имея BeginTrace/EndTrace проще вычленять хитрые куски логики, когда например начало в контроллере, а конец — внутри сервиса до первого сэйва.
Несмотря на то, что статья (и вся серия) это якобы про бизнес-логику по факту статья о работе с базой. И я не чтобы прям топлю за DDD, в котором рисуешь домен, который ничего не знает о Persistence или принижаю значимость базы данных (подавляющее большинство enterprise вокруг БД крутится, чаще всего одной из тройки реляционных), просто глянул в комментарии к прошлой статье о том, что обёртка есть только для одной БД и даже не особо умеет plain sql типа как в Dapper.
И вся логика начинается с фразы From<Db> — ну это понятно, что вроде как это "канал" и вроде как можно иные каналы описать… но по факту это просто иная разновидность EF, причём там уже под разные SQL базы есть неплохая кодовая база (хотя то, как реализована mysql мне лично не особо нравится). И она может быть в чём-то лучше, чем EF, в чём-то просто "иначе" ("привыкнешь")
А допустим, если сказать "очереди СМЭВ" — и это уже будет кагбэ за рамками статьи? Тоже вроде как "логика".
Всю первую часть предыдущей статьи я рассказывал, что канал может абстрагировать любую внешнюю систему. Странно, что вы увидели только БД. Тем более странно, что вы увидели только одну БД, когда я говорю что в качестве рантайма используется EF.Core, который поддерживает как минимум три базы.
И вся логика начинается с фразы From<Db>С From<Db> начинаются только запросы и только к базе данных. Только к той, которую вы привязали к каналу Db.
это просто иная разновидность EF
Мимо. Обёртка для DirectSQL, кстати, есть.
очереди СМЭВ
Делаете аспект СМЭВ, подключаете его к любому каналу и погнали.
В остальном — см. вот этот комментарий и мой ответ на него.
Ведь создание сущности — это команда, а получение Id — запрос.
По моему личному опыту, строго разделение на «команды» и «запросы» — довольно иллюзорно. Для команд рано или поздно (скорее рано) появится необходимость возвращать больше информации в ответе. Для запросов выяснится, что надо попутно записать информацию в аудит или счетчики, т.е. это уже будет не совсем чистый запрос.
_tecture.Save()
Выглядит как потенциально протекающая абстракция, ибо для других каналов может отсутствовать функция накопления операций (данных?) в памяти. Вот для работы в транзакции, например, это будет обоснованно, но всё равно хочется как то иначе это организовать (пока не знаю как).
Будем подождать 3ю часть этого сериала, пока интригующе, спасибо! :)
Мне было стыдно за свой интерпрайз-код настолько, что я сделал свой велосипед. За него стыдно меньше