Какие архитектуры использовал в проектах?

Архитектурные подходы в моих проектах

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

Монолитная архитектура (Monolithic)

Для небольших сервисов или стартапов с четко определенными границами часто выбирал классический монолит. Это позволяло быстро разрабатывать и деплоить приложение как единое целое. В Go это часто реализуется через структурированный проект с четким разделением слоев внутри одного модуля:

// Пример организации монолита в Go
package main

import (
    "github.com/gin-gonic/gin"
    "myapp/internal/config"
    "myapp/internal/database"
    "myapp/internal/handlers"
    "myapp/internal/repositories"
    "myapp/internal/services"
)

func main() {
    // Инициализация зависимостей
    cfg := config.Load()
    db := database.New(cfg.DB)
    repo := repositories.NewUserRepository(db)
    service := services.NewUserService(repo)
    handler := handlers.NewUserHandler(service)
    
    // Настройка маршрутов
    r := gin.Default()
    r.POST("/users", handler.CreateUser)
    r.GET("/users/:id", handler.GetUser)
    r.Run(":8080")
}

Микросервисная архитектура (Microservices)

Для сложных, высоконагруженных систем с независимо развивающимися компонентами применял микросервисный подход. Каждый сервис отвечал за конкретную бизнес-функцию (например, пользователи, платежи, уведомления) и разрабатывался как независимое Go-приложение. Коммуникация между сервисами осуществлялась через:

• gRPC для высокопроизводительного RPC
• HTTP/REST API для публичных интерфейсов
• События через Kafka или RabbitMQ для асинхронной коммуникации

// Пример gRPC сервиса в Go
package main

import (
    "log"
    "net"
    
    "google.golang.org/grpc"
    pb "myapp/proto/user"
    "myapp/internal/user_service"
)

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    
    s := grpc.NewServer()
    pb.RegisterUserServiceServer(s, &user_service.Server{})
    
    log.Println("User gRPC server starting...")
    s.Serve(lis)
}

Событийно-ориентированная архитектура (Event-Driven)

В системах, требующих высокой степени декомпозиции и реактивности, использовал EDA. Сервисы публиковали события в шину (Kafka), а другие сервисы реагировали на них. Это позволяло создавать гибкие, масштабируемые и отказоустойчивые системы, особенно в финансовых и аналитических проектах.

Архитектура на основе портов и адаптеров (Ports & Adapters / Hexagonal)

Для поддержания чистоты бизнес-логики и обеспечения высокой тестируемости применял гексагональную архитектуру. Ядро приложения (бизнес-логика) было полностью отделено от внешних зависимостей (базы данных, HTTP-фреймворки, сторонние API). Это достигалось через интерфейсы (порты) и их реализации (адаптеры).

// Пример разделения через интерфейсы в Go
package domain

// Порты (интерфейсы ядра)
type UserRepository interface {
    Save(user *User) error
    FindByID(id string) (*User, error)
}

type UserService struct {
    repo UserRepository // зависит только от интерфейса
}

package postgres

// Адаптер для PostgreSQL
type UserRepoAdapter struct {
    db *sql.DB
}

func (a *UserRepoAdapter) Save(user *domain.User) error {
    // Реализация для PostgreSQL
}

Слоистая архитектура (Layered)

В большинстве проектов применял слоистую организацию кода (часто в сочетании с другими архитектурами):

• Слой домена (Domain) — бизнес-сущности и правила
• Слой применения (Application/Service) — бизнес-процессы и координация
• Слой инфраструктуры (Infrastructure) — работа с внешними системами
• Слой представления (Presentation) — API handlers, контроллеры

CQRS (Command Query Responsibility Segregation)

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

Практические комбинации

В реальных проектах я часто комбинировал подходы:

1. Микросервисы + EDA — для масштабируемой распределенной системы аналитики.
2. Монолит + Hexagonal — для поддержания качества кода в относительно небольшом, но сложном приложении.
3. Микросервисы + CQRS — для высоконагруженной торговой платформы.

Выбор архитектуры всегда зависел от конкретных требований проекта: микросервисы для независимых команд и масштабирования, монолит для скорости разработки на ранних этапах, EDA для асинхронных и реактивных систем, гексагональная архитектура для долгосрочной поддерживаемости и тестируемости. Go, благодаря своей простой модели типов (интерфейсы) и эффективности в создании сетевых сервисов, является прекрасным языком для реализации всех этих архитектурных подходов.