Сколько слоев нужно будет заменить при добавлении Web Socket в чистой архитектуре?

Влияние добавления WebSocket на слои чистой архитектуры

При добавлении WebSocket в приложение, построенное по принципам чистой архитектуры (Clean Architecture), потребуется модификация или добавление нескольких слоев, но не обязательно их полная замена. Количество изменяемых слоев зависит от текущей структуры приложения и выбранного подхода к интеграции.

Основные слои, требующие изменений

1. Слой инфраструктуры (Infrastructure/Data Layer)

Этот слой претерпит наиболее значительные изменения, так как WebSocket представляет собой новый механизм транспорта данных.

// Пример WebSocket обработчика в слое инфраструктуры
package infrastructure

import (
    "github.com/gorilla/websocket"
    "net/http"
)

type WebSocketHandler struct {
    upgrader websocket.Upgrader
    hub      *WebSocketHub
}

func NewWebSocketHandler() *WebSocketHandler {
    return &WebSocketHandler{
        upgrader: websocket.Upgrader{
            CheckOrigin: func(r *http.Request) bool { return true },
        },
    }
}

func (h *WebSocketHandler) HandleConnection(w http.ResponseWriter, r *http.Request) {
    conn, err := h.upgrader.Upgrade(w, r, nil)
    if err != nil {
        return
    }
    
    client := NewWebSocketClient(conn)
    h.hub.Register(client)
    go client.ReadMessages()
}

2. Слой интерфейсов/презентации (Interface/Controller Layer)

Потребуется создать новые контроллеры или адаптеры для обработки WebSocket-сообщений:

// WebSocket контроллер, преобразующий сообщения в use case вызовы
package presentation

type WebSocketController struct {
    messageUseCase usecases.MessageUseCase
}

func (c *WebSocketController) HandleMessage(msg WebSocketMessage) {
    // Преобразование WebSocket сообщения в DTO
    requestDTO := c.mapToDTO(msg)
    
    // Вызов use case
    response, err := c.messageUseCase.Process(requestDTO)
    
    // Отправка ответа через WebSocket
    c.sendWebSocketResponse(response)
}

3. Слой use cases (Business Logic Layer)

Может потребоваться расширение существующих use cases или создание новых:

package usecases

type RealTimeMessageUseCase struct {
    repo repositories.MessageRepository
}

func (uc *RealTimeMessageUseCase) BroadcastMessage(msg domain.Message) error {
    // Бизнес-логика обработки сообщения
    if err := uc.validateMessage(msg); err != nil {
        return err
    }
    
    // Сохранение в репозитории
    if err := uc.repo.Save(msg); err != nil {
        return err
    }
    
    // Триггеринг события для реального времени
    uc.notifySubscribers(msg)
    
    return nil
}

4. Слой домена (Domain Layer)

Могут потребоваться новые сущности или value objects:

package domain

// Новая сущность для представления WebSocket соединения
type WebSocketConnection struct {
    ID        string
    UserID    string
    Connected bool
    CreatedAt time.Time
}

// События домена для реального времени
type MessageBroadcastedEvent struct {
    MessageID string
    Content   string
    Timestamp time.Time
}

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

WebSocket Hub/Manager

Централизованный менеджер для управления соединениями:

package infrastructure

type WebSocketHub struct {
    clients    map[*WebSocketClient]bool
    broadcast  chan []byte
    register   chan *WebSocketClient
    unregister chan *WebSocketClient
}

func (h *WebSocketHub) Run() {
    for {
        select {
        case client := <-h.register:
            h.clients[client] = true
        case client := <-h.unregister:
            if _, ok := h.clients[client]; ok {
                delete(h.clients, client)
                close(client.send)
            }
        case message := <-h.broadcast:
            for client := range h.clients {
                select {
                case client.send <- message:
                default:
                    close(client.send)
                    delete(h.clients, client)
                }
            }
        }
    }
}

Ключевые архитектурные решения

1. Адаптер для WebSocket - Создание адаптера, который преобразует WebSocket-сообщения в вызовы use cases
2. Инверсия зависимостей - WebSocket обработчики должны зависеть от интерфейсов use cases, а не наоборот
3. Изоляция бизнес-логики - Use cases не должны знать о существовании WebSocket

Практический подход к внедрению

Поэтапное внедрение WebSocket обычно включает:

1. Анализ текущих use cases на предмет поддержки реального времени
2. Создание интерфейсов для абстракции WebSocket функциональности
3. Реализацию инфраструктурных компонентов (обработчики, хабы)
4. Интеграцию с существующими use cases через паттерны Observer или Event-driven архитектуру
5. Тестирование изолированно каждого слоя

Заключение

В чистой архитектуре не требуется заменять слои полностью - вместо этого происходит их расширение и адаптация. Основные изменения затронут слой инфраструктуры (новые транспорты) и слой интерфейсов (новые контроллеры), в то время как доменный слой и use cases могут остаться практически неизменными, получая лишь дополнительные интерфейсы для поддержки реального времени. Ключевой принцип - сохранение инверсии зависимостей и независимости бизнес-логики от деталей реализации WebSocket.