Какой идеей можешь поделиться?

Идеи для улучшения разработки Java приложений

Идея 1: Observability-First подход в разработке

Моя идея: разработчики должны писать observability код параллельно с бизнес-логикой, а не добавлять логирование постфактум. Это означает:

• Структурированное логирование с корреляционными ID
• Метрики как часть API контракта
• Трейсинг встроенный в архитектуру

// Вместо этого:
public class OrderService {
    private static final Logger log = LoggerFactory.getLogger(OrderService.class);
    
    public Order create(CreateOrderRequest request) {
        log.info("Creating order");  // Неструктурированное логирование
        // ...
        return order;
    }
}

// Делай это:
@Service
public class OrderService {
    private final Logger log;
    private final MeterRegistry meterRegistry;
    private final Tracer tracer;
    
    public Order create(CreateOrderRequest request, String traceId) {
        try (var scope = tracer.spanBuilder("order.create")
                .setAttribute("order.id", request.orderId())
                .setAttribute("trace.id", traceId)
                .startScope()) {
            
            log.info("Creating order", Map.of(
                "order_id", request.orderId(),
                "user_id", request.userId(),
                "trace_id", traceId
            ));
            
            meterRegistry.counter("order.create.attempts").increment();
            
            Order order = doCreateOrder(request);
            
            meterRegistry.counter("order.create.success").increment();
            return order;
        } catch (Exception e) {
            meterRegistry.counter("order.create.failed").increment();
            throw e;
        }
    }
}

Преимущества:

• Проблемы в production видны сразу
• Легче делать post-mortem анализ
• Разработчики думают о надёжности с самого начала

Идея 2: Contract-Driven Development

Это развитие TDD. Вместо того чтобы сначала писать unit тесты, сначала опишите контракт API/компонента через OpenAPI/AsyncAPI, а затем используйте generated stubs для разработки:

# orders-api.yaml
openapi: 3.0.0
paths:
  /api/orders:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                userId:
                  type: string
                items:
                  type: array
      responses:
        201:
          description: Order created
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: string
                  status:
                    enum: [PENDING, CONFIRMED]

Затем код генерируется:

// Сгенерировано из OpenAPI
public interface OrdersApi {
    CreateOrderResponse createOrder(CreateOrderRequest request);
}

// Тебе нужно просто реализовать
@RestController
public class OrderController implements OrdersApi {
    @Override
    public CreateOrderResponse createOrder(CreateOrderRequest request) {
        // Реализуй бизнес-логику
        return new CreateOrderResponse(/* ... */);
    }
}

Преимущества:

• Single source of truth для API
• Frontend и backend синхронизированы
• Контрактные тесты между сервисами

Идея 3: Behavior-Driven Development для domain logic

Используй Scenario-based testing для сложной бизнес-логики:

// OrderScenarios.java (вместо 10 unit тестов)
public class OrderScenarios {
    
    @Test
    void scenario_customer_creates_order_and_pays() {
        // Given
        Customer customer = CustomerBuilder.aCustomer()
            .withBalance(1000)
            .build();
        Item item = ItemBuilder.anItem()
            .withPrice(99)
            .withQuantity(5)
            .build();
        
        // When
        Order order = orderService.create(
            customer,
            List.of(item)
        );
        Payment payment = paymentService.process(
            order,
            customer
        );
        
        // Then
        assertThat(order)
            .isInStatus(OrderStatus.CONFIRMED)
            .hasItems(item)
            .hasTotal(495);
            
        assertThat(payment)
            .isInStatus(PaymentStatus.SUCCESS)
            .hasReference(order.getId());
            
        assertThat(customer)
            .hasBalance(505);
    }
    
    @Test
    void scenario_customer_cancels_before_payment() {
        // Другой сценарий — другой результат
    }
}

Это лучше, чем:

• testCreateOrder()
• testCreateOrderWithNullItems()
• testPaymentProcessing()
• и ещё 7 других тестов

Идея 4: Vertical Slices вместо Horizontal Layers

Организуй код по feature, а не по техническому слою:

// Плохо (Horizontal)
src/
├── controllers/
│   ├── OrderController.java
│   ├── UserController.java
├── services/
│   ├── OrderService.java
│   ├── UserService.java
├── repositories/
│   ├── OrderRepository.java
│   ├── UserRepository.java

// Хорошо (Vertical Slices)
src/
├── orders/
│   ├── domain/
│   │   ├── Order.java
│   │   ├── OrderRepository.java (interface)
│   ├── application/
│   │   ├── CreateOrderService.java
│   ├── infrastructure/
│   │   ├── OrderRepositoryImpl.java
│   ├── presentation/
│   │   ├── OrderController.java
│
├── users/
│   ├── domain/
│   ├── application/
│   ├── infrastructure/
│   ├── presentation/

Преимущества:

• Feature можно развивать независимо
• Проще понять бизнес-логику
• Проще тестировать полный flow
• Микросервис можно вырезать легче

Идея 5: Async-by-Default для I/O операций

Все I/O операции (БД, API, файлы) должны быть асинхронными по умолчанию:

// Вместо:
public Order getOrder(String orderId) {
    return orderRepository.findById(orderId);  // Блокирует поток
}

// Делай:
public Mono<Order> getOrder(String orderId) {
    return orderRepository.findById(orderId);  // Non-blocking
}

// В контроллере:
@GetMapping("/orders/{id}")
public Mono<ResponseEntity<OrderDTO>> getOrder(@PathVariable String id) {
    return orderService.getOrder(id)
        .map(this::toDTO)
        .map(ResponseEntity::ok)
        .onErrorResume(this::handleError);
}

С Project Reactor можно обрабатывать тысячи запросов на одном потоке.

Идея 6: Immutability-First в domain

Все domain объекты должны быть immutable по умолчанию:

// Вместо:
public class Order {
    private String id;
    private List<Item> items;
    
    public void addItem(Item item) {  // ИЗМЕНЯЕТ состояние!
        items.add(item);
    }
}

// Делай:
public record Order(
    String id,
    List<Item> items
) {
    // Ничего не может быть изменено!
    // Создавай новые объекты для изменений
}

// Или для более сложных случаев:
public class Order {
    private final String id;
    private final List<Item> items;
    
    public Order withAddedItem(Item item) {
        List<Item> newItems = new ArrayList<>(items);
        newItems.add(item);
        return new Order(id, List.copyOf(newItems));
    }
}

Преимущества:

• Нет unexpected side effects
• Легче параллелизировать
• Проще тестировать
• Меньше baggy с null

Идея 7: Progressive Enhancement для API версионирования

Вместо /v1 и /v2, используй progressive enhancement:

@RestController
@RequestMapping("/api/orders")
public class OrderController {
    
    @PostMapping
    public ResponseEntity<OrderDTO> create(@RequestBody CreateOrderRequest request) {
        Order order = orderService.create(request);
        return ResponseEntity.status(201).body(toDTO(order));
    }
    
    // Старый клиент получит OrderDTO без новых полей
    // Новый клиент получит OrderDTOWithMetadata (через Content Negotiation)
    
    @PostMapping(produces = "application/vnd.company.order+json;version=2")
    public ResponseEntity<OrderDTOWithMetadata> createV2(
            @RequestBody CreateOrderRequest request) {
        Order order = orderService.create(request);
        return ResponseEntity.status(201).body(toDTOV2(order));
    }
}

Заключение

Моя главная идея: Java разработчики должны думать не только о коде, но о системе в целом. Это включает:

• Наблюдаемость (observability)
• Контракты (contracts)
• Бизнес сценарии (scenarios)
• Архитектура по фичам (features)
• Асинхронность (reactivity)
• Неизменяемость (immutability)
• Graceful evolution (версионирование)

Это создаёт более надёжные, масштабируемые и maintainable системы.