• Single Responsibility: каждый модуль или структура должна иметь одну причину для изменения, что упрощает тестирование и рефакторинг.
• Open/Closed: сущности должны быть открыты для расширения, но закрыты для модификации, достигается через интерфейсы в Go.
• Liskov Substitution: объекты должны заменяться экземплярами подтипов без нарушения работы программы, что важно для полиморфизма в Go.

package main

import "fmt"

// Order представляет заказ
type Order struct {
    ID    string
    Total float64
}

// OrderRepository интерфейс для принципа Dependency Inversion
type OrderRepository interface {
    Save(order Order) error
}

// MySQLOrderRepository реализация для MySQL
type MySQLOrderRepository struct{}

func (r MySQLOrderRepository) Save(order Order) error {
    fmt.Printf("Сохранение заказа %s в MySQL\n", order.ID)
    return nil
}

// OrderService отвечает только за бизнес-логику (Single Responsibility)
type OrderService struct {
    repo OrderRepository
}

func NewOrderService(repo OrderRepository) *OrderService {
    return &OrderService{repo: repo}
}

func (s *OrderService) CreateOrder(order Order) error {
    // Бизнес-логика, например, валидация
    if order.Total <= 0 {
        return fmt.Errorf("неверная сумма заказа")
    }
    return s.repo.Save(order)
}

func main() {
    repo := MySQLOrderRepository{}
    service := NewOrderService(repo)
    order := Order{ID: "123", Total: 100.0}
    if err := service.CreateOrder(order); err != nil {
        fmt.Println("Ошибка:", err)
    }
}

• Как вы применяете SOLID в Go, учитывая отсутствие наследования? — Использую композицию и интерфейсы: например, Dependency Inversion через внедрение зависимостей в структуры, что делает код тестируемым и гибким.
• Какие сложности возникают при внедрении SOLID в микросервисах на Go? — Может увеличиться количество интерфейсов и структур, но это окупается лёгкостью поддержки и изоляцией сервисов, что критично для микросервисной архитектуры.

1. Начните с Single Responsibility: разбейте крупные функции на меньшие, отвечающие за одну задачу, и используйте интерфейсы для абстракции.
2. Практикуйте Dependency Inversion в тестах: мокируйте зависимости через интерфейсы для unit-тестирования без реальных баз данных или внешних сервисов.