SOLID простыми словами или как использовать ChatGPT не во вред человечеству, расскажу на примере в пару запросов.

В одном романе для того, чтобы подчеркнуть бесспорную красоту и поразительную сексуальность одной из героинь, автор использовал фразу: "She was a such kind of woman, that every man look at twice". Что в литературном переводе можно понять: "Одна была такой женщиной, что каждый мужчина оборачивался ей в след".

И точно такую же фразу я могу применить к бесподобной книге "Предметно-ориентированное проектирование (DDD)" Эванса Эрика. К ней хочется возвращаться каждый раз, когда ты садишься за проектирование системы в незнакомой тебе области. Словно маяк во время шторма, она помогает вести вашу галеру через сложности, чтобы все гребцы увидели землю, а проект увидел успешный старт.

И в этом обзоре, я расскажу, почему, по моему мнению, это MUSH HAVE книга для каждого middle+ разработчика.

• взглянем на примеры стандартного управления транзакциями с помощью аннотаций,
• поймём — когда решить задачу с помощью аннотаций не получится,
• и, судя по заголовку статьи, дадим пример реализации транзакционного исполнения кода в новом потоке, создавемых с помощью Spring TaskExecutor.

После прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на Хабре и не только, удаляется мало внимания.

Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.

Привет, Хабр! Когда я изучал паттерны проектирования, я делал это с помощью прочтения двух книг: простую и понятную книгу от Head First одновременно со сложной и менее понятной книгой от Банды Четырех. Ниже описан мой опыт того, как именно я это делал, плюс выводы, впечатления и советы

public class Singleton {
    private static Singleton instance;
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Давным-давно в далекой Галактике, когда сестры Вачовски еще были братьями, искусственный разум в лице Архитектора поработил человечество и создал Матрицу… Всем привет, это снова Максим Кравец из Holyweb, и сегодня я хочу поговорить про Dependency Injection, то есть про внедрение зависимостей, или просто DI. Зачем? Возможно, просто хочется почувствовать себя Морфеусом, произнеся сакраментальное: «Я не могу объяснить тебе, что такое DI, я могу лишь показать тебе правду».  

От переводчика: На проекте, где я работаю, сейчас идет активное переписывание логики, ранее реализованной в виде богатой модели предметной области (с использованием Active Record и Unit of Work). Новый подход включает в себя классы сущностей без поведения и служб без состояния, взаимодействующих посредством интерфейсов — фактически, он представляет собой анемичную модель, с перспективой перехода в дальнейшем на микросервисную архитектуру. Наблюдая в режиме реального времени, как «макаронный монстр» из примерно полутора миллионов LOC постепенно обретает форму, как упрощаются тестирование, масштабирование и кастомизация системы под нуждый различных заказчиков, я был весьма удивлен, узнав, что такой подход часто рассматривается как архитектурный анти-шаблон. Пытаясь разобраться в причинах этого, я наткнулся на данную статью и размещаю здесь ее перевод, чтобы обсудить с сообществом плюсы и минусы подхода.

Оригинал: The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design

Всем доброго времени суток. В этой статье речь пойдет о паттерне Observer. Все кто связан с iOS разработкой наверняка сталкивались с инструментами в основе работы которых лежит этот паттерн. Например NotificationCenter, KVO или великий и могучий RxSwift который настолько сейчас популярен. В этой статье я на простом примере разберу принцип работы данного паттерна.

Любите ли вы комиксы так, как люблю их я? Если нет, то вы просто неправильно их смотрите! Переписать сюжет в виде программного кода — и отдых, и развлечение, и возможность потренироваться. 

Всем привет, это снова Макс Кравец из Holyweb, и сегодня мы будем косплеить Ивана Ванко, то есть делать дронов. Много дронов. Для этого нам понадобится целая фабрика. Поехали!

Далее мы разберём примеры того, как я использую СТРАТЕГИЮ в Javascript, и как он используется реальной библиотекой, для разбиения её на небольшие части.

Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.

Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.

Главный Технический Императив Разработки ПО — управление сложностью

— Совершенный код

Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:

• состояние всего приложения хранится в одном месте
• единственный способ изменить состояние — отправка Action'ов
• все изменения происходят с помощью чистых функций

Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

Введение