Мы решили внести свой скромный вклад в развитие комьюнити и перевели оригинальную статью. Статья опубликована на сайте Simplilearn.

Мы все больше полагаемся на данные для выполнения задач в работе и повседневной жизни. Приложения, сервисы, ПО, мобильные устройства и другие элементы объединяются в сложную и разветвленную паутину, которая затрагивает большинство сфер нашей жизни.

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

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

В этой статье обсудим, что из себя представляет изолированность транзакций в БД, какие есть уровни изоляции транзакций, как их установить, какие бывают аномалии на разных уровнях, и что такое MVCC. Естественно, всё на простых примерах.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).

Фантомное чтение — транзакция повторно выполняет запрос, возвращающий набор строк для некоторого условия, и обнаруживает, что набор строк, удовлетворяющих условию, изменился из-за транзакции, завершившейся за это время.

Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.

internal class GcIsWeird
{
    ~GcIsWeird()
    {
        Console.WriteLine("Finalizing instance.");
    }

    public int data = 42;

    public void DoSomething()
    {
        Console.WriteLine("Doing something. The answer is ... " + data);
        // Some other code...
        Console.WriteLine("Finished doing something.");
    }
}

В данной статье вы встретите сразу два источника информации:

1. Полный курс по работе Garbage Collector на русском языке: CLRium #6 (текущий семинар здесь)
2. Перевод статьи из BOTR "Устройство сборщика мусора" от Маони Стевенс.

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Всем привет! Давайте знакомиться ;) Я Аня, и я php разработчик. Основной стек - Magento. С недавних пор начала посматривать налево на Symfony и писать свои Pet Projects на этом фреймворке.

Мне всегда нравилось писать решения которые легко бы расширялись / адаптировались под требования бизнеса (заказчика). И мне всегда хотелось сделать это более 'правильно' и красиво. Так я и познакомилась с понятиями чистой архитектурой.

Мой пост ни в коем случае не претендует на самый правильный. Но позвольте мне здесь донести свои идеи. В комментариях буду рада услышать конструктивную критику к данному посту.

Для нетерпеливых, вот прямая ссылка на гитхаб

Всем привет! Предметно-ориентированное проектирование, на мой взгляд, является недопонятым подходом, о котором многие говорят, но немногие его действительно применяют.

Одним из относительно простых в реализации и полезных в архитектурном смысле паттернов, на мой взгляд, являются события предметной области (Domain Events). В данной статье я бы хотел рассказать о возможных вариантах реализации этого шаблона DDD с использованием .NET.

Привет, Хабравчане! Меня зовут Валентин, я backend‑разработчик в компании Bimeister.
Уже почти как год вместе с командой разрабатываем новый продукт с применением Domain‑driven design подхода. Как же так получилось?

Так вот, разработка начиналась совершенно с нуля и это была хорошая возможность применить данный подход и попробовать его на практике. В момент начала разработки, перед нашей командой сразу встал вопрос: «А как же хранить аггрегаты, сущности, value‑object'ы в базе данных с использованием EF Core? ». Если вы только начинаете применять DDD и перед вами и вашей командой встала такая же проблема, то эта статья поможет вам приблизиться к ее решению, да пребудет с вами сила Эванса!

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере.

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?