Эта статья является переводом материала «Tackling Complexity in the Heart of DDD».

Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD) тому, кто понятия об этом не имеет. Это, особенно если делать кратко, непросто. Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?

Чтобы найти порядок в кажущемся хаосе, я хочу проанализировать методологию DDD с довольно необычной точки зрения — применив DDD к самому DDD. В конце концов, эта методология предназначена для работы со сложными доменами, не так ли?

Самый распространённый стандарт для обмена информацией внутри приложений — это REST API. Его все любят, но знают, что он не идеален. В этой статье обсудим его альтернативу — GraphQL. Мы расскажем, в чём преимущество GraphQL, как выглядят запросы и с чего начать.

В предыдущей статье я описал обходной путь, который был добавлен в .NET 6, чтобы инструменты EF Core, которые ранее полагались на существование определённых методов, таких как CreateHostBuilder, продолжали работать с новыми минимальными API хостинга.

В этой статье я рассмотрю связанное изменение, обеспечивающее работу интеграционного тестирования с WebApplicationFactory в .NET 6. WebApplicationFactory использовала тот же класс HostFactoryResolver, что и инструменты EF Core, но потребовалось ещё несколько изменений, которые я рассмотрю в этой статье.

Написание кода на любом языке программирования сопряжено с исследованием особенностей, которые позволяют быстро и эффективно написать алгоритм. В этой статье попробуем рассказать чуть больше о структуре файлов, которые получаются в результате компиляции приложений, написанных на языке программирования C#.

Массовый переход от монолитов к микросервисам решает ряд проблем:

• раздельный деплой и рефакторинг;

• удобное масштабирование частей системы;

• прозрачное разграничение ответственности команд;

• снижение бласт-радиуса;

• снижение когнитивной нагрузки на разработчика.

При этом создает другие проблемы: взаимодействие сервисов существенно сложнее и дороже, чем взаимодействие объектов в памяти. Частично упростить его можно с помощью протокола gRPC.

gRPC дает возможность зафиксировать в репозитории контракты межсервисных вызовов, строгую типизацию, стриминг, кросс-платформенную кодогенерацию и множество других полезных для межсервисного общения вещей.

Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация. 

По материалам выступления на конференции DotNext.

К старту курса по разработке на C# делимся материалом из блога .NET о том, как компилятор C# 10 и .NET 6 упрощают программирование, как они обращаются с форматированием, а также о причинах конкретных решений команды .NET. И это далеко не всё. За подробностями приглашаем под кат.

Снова привет, Хабр! 

В первой части статьи мы разбирали, что такое изоляция микросервисов, как в этом помогают переключатели функциональности, и как создать простое ASP.NET приложение в с поддержкой feature toggles, которое будет показывать прогноз погоды. В этой части закончим работу над ним — напишем заглушку, сделаем экспериментальную конечную точку, функциональность которой можно включать или выключать, не останавливая работу приложения, и разберёмся с экстренными ситуациями, которые могут возникнуть при разработке приложения.

Дисклеймер: в статье много тяжёлых иллюстраций, берегите мобильный интернет.

До сих пор в этой серии я рассматривал новые минимальные API хостинга, созданные с использованием WebApplication и WebApplicationBuilder. Они обеспечивают более простую модель для создания веб-приложений, сохраняя при этом те же общие функциональные возможности, что и приложения .NET Core 3.x/5 на основе универсального хоста.

Однако c этим упрощением есть проблемы. Более сложный код запуска в ранних версиях, обычно разделённый между Program.cs и Startup, имел преимущества, так как он предоставлял хорошо известные точки расширения (hooks), которые инструменты могли использовать для перехвата процесса запуска приложения.

Классическим примером этого является инструментарий EF Core^*EN. Если вы когда-либо использовали EF Core, возможно, вы знакомы с проблемами, возникающими при попытке изменить код запуска. А уж когда фреймворк меняет свой код запуска по умолчанию, понятно, что без проблем не обойтись!

Привет, Хабр! Если вы работаете с микросервисами, то знаете, что они имеют свойство образовывать некоторую связанность. Хорошо, когда связи между микросервисами однонаправленные, но всё становится сложнее, если возникают циклические зависимости.

Такие зависимости приводят к сложностям развертывания, которые можно преодолеть по-разному — например, используя docker compose. Но на локальном компьютере обычно не возникает необходимости поднятия всей инфраструктуры, потому что разработчика для выполнения задачи обычно интересует какая-нибудь конкретная её часть. В этом случае пригодятся средства изоляции микросервисов.

Меня зовут ​​Сергей Прохоров, я техлид бэкенд-разработки в Ak Bars Digital, и давайте вместе рассмотрим, как реализовать такую изоляцию на примере микросервиса веб-API ASP.NET Core. Метод изоляции основан на использовании feature toggles, или переключателей функциональности, о которых и пойдёт речь в двух частях статьи.

В моем предыдущем посте я рассмотрел код WebApplicationBuilder, включая некоторые из его вспомогательных классов, таких как ConfigureHostBuilder и BootstrapHostBuilder. В конце поста мы создали экземпляр WebApplicationBuilder и вызвали Build() для создания WebApplication. В этом посте мы немного рассмотрим код, лежащий в основе WebApplication, и сосредоточимся на настройке промежуточного ПО и конечных точек.

Привет! Я Антон Антонов, Full Stack Developer. Расскажу, что помогает мне исправлять ошибки в коде.

В свое время я случайно узнал, что исключения в моём горячо любимом языке C# — и, как следствие, во всем .NET — не все ведут себя одинаково. Причём, что ещё гораздо интереснее, далеко не все и не всегда могут быть обработаны и перехвачены. Что, казалось бы, полностью противоречит интуитивному восприятию конструкции try-catch-finally. 

Изучая этот вопрос, я находил всё новые и новые исключения среди исключений, которые оказывались «сильнее», чем конструкция try-catch-finally. К тому моменту, когда мой список вырос до 7 пунктов, я внезапно осознал, что нигде не было такого места, где можно было бы найти их все сразу. Максимум — 2 или 3 случая, рассмотренных в одной статье. 

Это и подтолкнуло меня к написанию данной статьи. 

Часть 1. ConfigurationManager
Часть 2. WebApplicationBuilder

В предыдущем посте я сравнивал новый WebApplication с универсальным хостом. В этом посте я рассмотрю код, лежащий в основе WebApplicationBuilder, чтобы увидеть, как он обеспечивает более чистый, минимальный API хостинга, при этом обеспечивая ту же функциональность, что и универсальный хост.

Всего есть 3 типа жизни (ServiceLifetime) экземпляра:

Singleton - одиночка, создается один раз и используется во время использования всего процесса, метод .AddSingleton<T>().

Transient - временный, создается каждый раз при запросе его из провайдера, метод .AddTransient<T>().

Scoped - ограниченный, новый экземпляр создается в определённой области видимости (scope) в интерфейсе IServiceScope. Добавляется методом .AddScoped<T>().

Ссылка на картинку: https://stackoverflow.com/a/64776798

Привет! Я — Роман Махнык, .NET developer в NIX. Уже четвертый год я занимаюсь разработкой коммерческих проектов, а сейчас проектирую разные приложения на основе облачных решений.

В своей статье я буду описывать фреймворк gRPC для API. Он достаточно свежий, но уже зарекомендовал себя как перспективное решение. Суть gRPC в максимально упрощенной коммуникации сервисов. Также важно, что в gRPC данные отправляются по постоянному каналу без сериализации и роутов эндпоинтов.

Если вы только начинаете работу с API или хотите лучше разобраться именно в gRPC — эта статья для вас.

Удивительно, сколько полезностей можно узнать за один хабрамитап Хабр ПРО. Например, какая судьба ждёт монолит при переходе на микросервисы и кто отвечает за общий код между двумя микросервисами.

Эти и другие вопросы обсуждались 25 ноября в выпуске «Хабрамитап про микросервисы: отвечаем на вопросы с Хабр Q&A». Вебкаст посетил наш сотрудник — руководитель направления автоматизации в Россельхозбанке (РСХБ) Денис Рылеев.

На протяжении эфира Денис отвечал на вопросы о микросервисах, которые задавал ведущий хабрамитапа Андрей Аврамчук, подобравший самые интересные топики от зрителей вебкаста и пользователей бывшего Тостера — нынешнего Хабр Q&A. Кроме Дениса выступал ещё один эксперт — системный инженер компании EPAM Михаил Чугунов.

Из этой статьи даже начинающий разработчик поймёт, что такое микросервисы и в каких ситуациях они применяются. Денис и Михаил постарались ответить на все вопросы максимально доступным языком. Мы выделили несколько категорий вопросов:

• Введение в микросервисы
• Серебряная пуля Фредерика Брукса
• Архитектура, разворачивание и API Gateway
• Какую литературу советуют почитать профессионалы

Заранее обрадуем жаждущих именно услышать специалистов: каждый вопрос сопровождается ссылкой с вшитым тайм-кодом, так что долго искать ответы в записи вебкаста не придётся.

Хороший вопрос требует хорошего ответа. Приступим.

Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.

Многие при этом не задумываются, правильно ли они пилят микросервисы. Как в синдроме утенка: увиденное самым первым становится единственно верным решением.

Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.

Инверсия зависимостей - один из принципов SOLID, который лежит в основе построения гексагональной архитектуры приложения. Существует множество статей, которые раскрывают суть принципа и объясняют как его применять. И, возможно, читатель уже знаком с ними. Но в рамках данной статьи будет продемонстрирован подробный разбор "тактических" приемов для успешного использования инверсии зависимостей и, возможно, в этом смысле даже искушенный читатель сможет найти для себя что-то новое. Примеры представлены на языке программирования Java с соответствующим окружением, но при этом для чтения достаточно понимания похожих языков программирования.

Опытные .NET-разработчики знают, что даже несмотря на наличие в .NET сборщика мусора (Garbage Collector), утечки памяти все равно возникают с завидной регулярностью. Утечки возможны не из-за ошибок в сборщике мусора, а потому что даже в управляемом коде есть множество способов их появления.

В этой статье мы пройдемся по наиболее частым причинам возникновения утечек памяти в .NET-приложениях. Все примеры написаны на C#, но описанные проблемы и способы их решения справедливы и для других .NET-языков.

Недавно я натолкнулся в нашем коде на использование пакета MediatR. Это заинтересовало меня. Почему я должен использовать MediatR? Какие преимущества он мне предоставляет? Здесь я собираюсь рассмотреть эти вопросы.