Go에서 MVC 및 DDD 계층 아키텍처 비교: 상세 가이드

Go 언어 MVC 및 DDD 계층 아키텍처의 상세 비교

MVC와 DDD는 백엔드 개발에서 널리 사용되는 두 가지 계층 아키텍처 개념입니다. MVC(Model-View-Controller)는 더 쉬운 디커플링 및 계층화를 위해 사용자 인터페이스, 비즈니스 로직 및 데이터 모델을 분리하는 데 주로 사용되는 디자인 패턴인 반면, DDD(Domain-Driven Design)는 비즈니스 도메인 모델을 구축하여 복잡한 시스템의 설계 및 유지 관리 어려움을 해결하는 데 목표를 둔 아키텍처 방법론입니다.

Java 생태계에서는 많은 시스템이 점진적으로 MVC에서 DDD로 전환되었습니다. 그러나 단순성과 효율성을 옹호하는 Go, Python 및 NodeJS와 같은 언어에서는 MVC가 주류 아키텍처로 남아 있습니다. 아래에서는 Go 언어를 기반으로 MVC와 DDD 간의 디렉토리 구조 차이점을 구체적으로 논의합니다.

MVC 다이어그램 구조

+------------------+
|      View        | 사용자 인터페이스 레이어: 데이터 표시 및 사용자 상호 작용을 담당합니다 (예: HTML 페이지, API 응답)
+------------------+
|   Controller     | 컨트롤러 레이어: 사용자 요청을 처리하고, 서비스 로직을 호출하고, 모델 및 뷰를 조정합니다
+------------------+
|      Model       | 모델 레이어: 데이터 객체 (예: 데이터베이스 테이블 구조) 및 일부 비즈니스 로직을 포함합니다 (종종 서비스 레이어에 흩어져 있음)
+------------------+

DDD 다이어그램 구조

+--------------------+
|   User Interface   | 사용자 상호 작용 및 표시를 담당합니다 (예: REST API, 웹 인터페이스)
+--------------------+
| Application Layer  | 비즈니스 프로세스를 조정합니다 (예: 도메인 서비스 호출, 트랜잭션 관리), 핵심 비즈니스 규칙은 포함하지 않습니다
+--------------------+
|   Domain Layer     | 핵심 비즈니스 로직 레이어: 집계 루트, 엔터티, 값 객체, 도메인 서비스 등을 포함하며, 비즈니스 규칙을 캡슐화합니다
+--------------------+
| Infrastructure     | 기술적 구현을 제공합니다 (예: 데이터베이스 액세스, 메시지 큐, 외부 API)
+--------------------+

MVC와 DDD의 주요 차이점

코드 구성 로직
- MVC는 기술 기능별로 계층화(컨트롤러/서비스/DAO)하여 기술 구현에 중점을 둡니다.
- DDD는 비즈니스 도메인별로 모듈을 분할(예: 주문 도메인, 결제 도메인)하여 제한된 컨텍스트를 통해 핵심 비즈니스 로직을 격리합니다.
비즈니스 로직의 전달자
- MVC는 일반적으로 빈혈 모델을 채택하여 데이터(모델)와 동작(서비스)을 분리하므로 로직이 분산되어 유지 관리 비용이 높습니다.
- DDD는 집계 루트 및 도메인 서비스를 통해 풍부한 모델을 달성하여 비즈니스 로직을 도메인 레이어에 집중시키고 확장성을 향상시킵니다.
적용 가능성 및 비용
- MVC는 개발 비용이 낮고 요구 사항이 안정적인 중소규모 시스템에 적합합니다.
- DDD는 사전 도메인 모델링 및 통합 언어가 필요하므로 복잡한 비즈니스 및 장기적인 진화 요구 사항이 있는 대규모 시스템에 적합하지만 팀은 도메인 추상화 기능을 갖추어야 합니다. 예를 들어 전자 상거래 프로모션 규칙에서 DDD는 로직이 여러 서비스에 분산되는 것을 방지할 수 있습니다.

Go 언어 MVC 디렉토리 구조

MVC는 주로 뷰, 컨트롤러 및 모델의 세 가지 레이어로 나뉩니다.

gin-order/
├── cmd
│   └── main.go                  # 애플리케이션 진입점, Gin 엔진 시작
├── internal
│   ├── controllers              # 컨트롤러 레이어 (HTTP 요청 처리), 핸들러라고도 함
│   │   └── order
│   │       └── order_controller.go  # 주문 모듈용 컨트롤러
│   ├── services                 # 서비스 레이어 (비즈니스 로직 처리)
│   │   └── order
│   │       └── order_service.go       # 주문 모듈용 서비스 구현
│   ├── repository               # 데이터 액세스 레이어 (데이터베이스와 상호 작용)
│   │   └── order
│   │       └── order_repository.go    # 주문 모듈용 데이터 액세스 인터페이스 및 구현
│   ├── models                   # 모델 레이어 (데이터 구조 정의)
│   │   └── order
│   │       └── order.go               # 주문 모듈용 데이터 모델
│   ├── middleware               # 미들웨어 (예: 인증, 로깅, 요청 인터셉션)
│   │   ├── logging.go             # 로깅 미들웨어
│   │   └── auth.go                # 인증 미들웨어
│   └── config                   # 구성 모듈 (데이터베이스, 서버 구성 등)
│       └── config.go                # 애플리케이션 및 환경 구성
├── pkg                          # 공통 유틸리티 패키지 (예: 응답 래퍼)
│   └── response.go              # 응답 처리 유틸리티 메서드
├── web                          # 프런트엔드 리소스 (템플릿 및 정적 자산)
│   ├── static                   # 정적 리소스 (CSS, JS, 이미지)
│   └── templates                # 템플릿 파일 (HTML 템플릿)
│       └── order.tmpl           # 주문 모듈용 뷰 템플릿 (HTML 렌더링이 필요한 경우)
├── go.mod                       # Go 모듈 관리 파일
└── go.sum                       # Go 모듈 종속성 잠금 파일

Go 언어 DDD 디렉토리 구조

DDD는 주로 인터페이스, 애플리케이션, 도메인 및 인프라의 네 가지 레이어로 나뉩니다.

go-web/
│── cmd/
│   └── main.go               # 애플리케이션 진입점
│── internal/
│   ├── application/          # 애플리케이션 레이어 (도메인 로직 조정, 사용 사례 처리)
│   │   ├── services/         # 서비스 레이어, 비즈니스 로직 디렉토리
│   │   │   └── order_service.go # 주문 애플리케이션 서비스, 도메인 레이어 비즈니스 로직 호출
│   ├── domain/               # 도메인 레이어 (핵심 비즈니스 로직 및 인터페이스 정의)
│   │   ├── order/            # 주문 집계
│   │   │   ├── order.go      # 주문 엔터티 (집계 루트), 핵심 비즈니스 로직 포함
│   │   ├── repository/       # 일반 리포지토리 인터페이스
│   │   │   ├── repository.go # 일반 리포지토리 인터페이스 (CRUD 작업)
│   │   │   └── order_repository.go # 주문 리포지토리 인터페이스, 주문 데이터에 대한 작업 정의
│   ├── infrastructure/       # 인프라 레이어 (도메인 레이어에서 정의된 인터페이스 구현)
│   │   ├── repository/       # 리포지토리 구현
│   │   │   └── order_repository_impl.go  # 주문 리포지토리 구현, 구체적인 주문 데이터 저장
│   └── interfaces/           # 인터페이스 레이어 (HTTP 인터페이스와 같은 외부 요청 처리)
│   │   ├── handlers/         # HTTP 핸들러
│   │   │  └── order_handler.go # 주문용 HTTP 핸들러
│   │   └── routes/
│   │   │   ├── router.go     # 기본 라우터 유틸리티 설정
│   │   │   └── order-routes.go # 주문 라우트 구성
│   │   │   └── order-routes-test.go # 주문 라우트 테스트
│   └── middleware/           # 미들웨어 (예: 인증, 인터셉션, 권한 부여 등)
│   │   └── logging.go        # 로깅 미들웨어
│   ├── config/               # 서비스 관련 구성
│   │   └── server_config.go  # 서버 구성 (예: 포트, 시간 초과 설정 등)
│── pkg/                      # 재사용 가능한 공용 라이브러리
│   └── utils/                # 유틸리티 클래스 (예: 로깅, 날짜 처리 등)

Go 언어 MVC 코드 구현

Controller (인터페이스 레이어) → Service (비즈니스 로직 레이어) → Repository (데이터 액세스 레이어) → Model (데이터 모델)

계층화된 코드

컨트롤러 레이어

// internal/controller/order/order.go
package order

import (
    "net/http"
    "strconv"
    "github.com/gin-gonic/gin"
    "github.com/gin-order/internal/model"
    "github.com/gin-order/internal/service/order"
    "github.com/gin-order/internal/pkg/response"
)

type OrderController struct {
    service *order.OrderService
}

func NewOrderController(service *order.OrderService) *OrderController {
    return &OrderController{service: service}
}

func (c *OrderController) GetOrder(ctx *gin.Context) {
    idStr := ctx.Param("id")
    id, _ := strconv.ParseUint(idStr, 10, 64)

    order, err := c.service.GetOrderByID(uint(id))
    if err != nil {
        response.Error(ctx, http.StatusNotFound, "Order not found")
        return
    }

    response.Success(ctx, order)
}

func (c *OrderController) CreateOrder(ctx *gin.Context) {
    var req model.Order
    if err := ctx.ShouldBindJSON(&req); err != nil {
        response.Error(ctx, http.StatusBadRequest, "Invalid request")
        return
    }

    if err := c.service.CreateOrder(&req); err != nil {
        response.Error(ctx, http.StatusInternalServerError, "Create failed")
        return
    }

    response.Success(ctx, req)
}

라우트 구성

// cmd/server/main.go
package main

import (
    "github.com/gin-gonic/gin"
    "github.com/gin-order/internal/controller/order"
    "github.com/gin-order/internal/pkg/database"
    "github.com/gin-order/internal/repository/order"
    "github.com/gin-order/internal/service/order"
)

func main() {
    // 데이터베이스 초기화
    db := database.NewGORM()

    // 의존성 주입
    orderRepo := order_repo.NewMySQLOrderRepository(db)
    orderService := order_service.NewOrderService(orderRepo)
    orderController := order_controller.NewOrderController(orderService)

    // 라우터 생성
    r := gin.Default()

    // 미들웨어 등록
    r.Use(middleware.Logger())

    // 라우트 그룹
    apiGroup := r.Group("/api")
    {
        orderGroup := apiGroup.Group("/orders")
        {
            orderGroup.GET("/:id", orderController.GetOrder)
            orderGroup.POST("", orderController.CreateOrder)
        }
    }

    // 서비스 시작
    r.Run(":8080")
}

서비스 레이어

// internal/service/order/service.go
package order

import (
    "github.com/gin-order/internal/model"
    "github.com/gin-order/internal/repository/order"
)

type OrderService struct {
    repo order.OrderRepository
}

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

func (s *OrderService) GetOrderByID(id uint) (*model.Order, error) {
    return s.repo.FindByID(id)
}

func (s *OrderService) CreateOrder(order *model.Order) error {
    return s.repo.Create(order)
}

데이터 액세스 레이어 (리포지토리)

// internal/repository/order/interface.go
package order

import "github.com/gin-order/internal/model"

type OrderRepository interface {
    FindByID(id uint) (*model.Order, error)
    Create(order *model.Order) error
    FindByStatus(status string) ([]model.Order, error)
}

// internal/repository/order/mysql.go
package order

import (
    "gorm.io/gorm"
    "github.com/gin-order/internal/model"
)

type MySQLOrderRepository struct {
    db *gorm.DB
}

func NewMySQLOrderRepository(db *gorm.DB) OrderRepository {
    return &MySQLOrderRepository{db: db}
}

func (r *MySQLOrderRepository) FindByID(id uint) (*model.Order, error) {
    var order model.Order
    if err := r.db.First(&order, id).Error; err != nil {
        return nil, err
    }
    return &order, nil
}

func (r *MySQLOrderRepository) Create(order *model.Order) error {
    return r.db.Create(order).Error
}

func (r *MySQLOrderRepository) FindByStatus(status string) ([]model.Order, error) {
    var orders []model.Order
    if err := r.db.Where("status = ?", status).Find(&orders).Error; err != nil {
        return nil, err
    }
    return orders, nil
}

모델 레이어

// internal/model/order.go
package model

import "time"

type Order struct {
    OrderID     uint      `gorm:"primaryKey;column:order_id"`
    OrderNo     string    `gorm:"uniqueIndex;column:order_no"`
    UserID      uint      `gorm:"index;column:user_id"`
    OrderName   string    `gorm:"column:order_name"`
    Amount      float64   `gorm:"type:decimal(10,2);column:amount"`
    Status      string    `gorm:"column:status"`
    CreatedAt   time.Time `gorm:"column:created_at"`
    UpdatedAt   time.Time `gorm:"column:updated_at"`
}

func (Order) TableName() string {
    return "orders"
}

Go 언어 MVC 모범 사례

인터페이스 분리 원칙

리포지토리 레이어는 인터페이스를 정의하여 여러 데이터베이스 구현을 지원합니다.

// Mock 구현으로 쉽게 전환
type MockOrderRepository struct {}
func (m *MockOrderRepository) FindByID(id uint) (*model.Order, error) {
    return &model.Order{OrderNo: "mock-123"}, nil
}

통합 응답 형식

// pkg/response/response.go
func Success(c *gin.Context, data interface{}) {
    c.JSON(http.StatusOK, gin.H{
        "code":    0,
        "message": "success",
        "data":    data,
    })
}

미들웨어 체인

// 글로벌 미들웨어
r.Use(gin.Logger(), gin.Recovery())

// 라우트 그룹 미들웨어
adminGroup := r.Group("/admin", middleware.AuthJWT())

데이터베이스 마이그레이션

GORM AutoMigrate 사용:

db.AutoMigrate(&model.Order{})

Go 언어 DDD 코드 구현 및 모범 사례

도메인 모델에 집중

DDD는 도메인 모델 구축을 강조하고 집계, 엔터티 및 값 객체를 사용하여 비즈니스 로직을 구성합니다.

Go에서 엔터티 및 값 객체는 일반적으로 struct로 정의됩니다.

// 엔터티
type User struct {
    ID   int
    Name string
}

계층 아키텍처

DDD는 일반적으로 계층 아키텍처를 채택합니다. Go 프로젝트는 다음 구조를 따를 수 있습니다.

도메인 레이어: 핵심 비즈니스 로직, 예: 도메인 디렉토리 아래의 엔터티 및 집계.
애플리케이션 레이어: 사용 사례 및 비즈니스 프로세스 조정.
인프라 레이어: 데이터베이스, 캐싱, 외부 API 등에 대한 어댑터.
인터페이스 레이어: HTTP, gRPC 또는 CLI 인터페이스를 제공합니다.

의존성 역전

도메인 레이어는 인프라 레이어에 직접 의존해서는 안 됩니다. 대신 의존성 역전을 위해 인터페이스에 의존합니다.

참고: DDD 아키텍처의 핵심은 의존성 역전(DIP)입니다. 도메인은 가장 안쪽의 핵심으로, 비즈니스 규칙 및 인터페이스 추상화만 정의합니다. 다른 레이어는 구현을 위해 도메인에 의존하지만 도메인은 외부 구현에 의존하지 않습니다. 육각형 아키텍처에서 도메인 레이어는 코어에 위치하는 반면 다른 레이어(예: 애플리케이션, 인프라)는 도메인에서 정의한 인터페이스를 구현하여 데이터베이스 작업, API 호출과 같은 구체적인 기술 세부 사항을 제공하여 도메인과 기술 구현 간의 디커플링을 달성합니다.

// 도메인 레이어: 인터페이스 정의
type UserRepository interface {
    GetByID(id int) (*User, error)
}

// 인프라 레이어: 데이터베이스 구현
type userRepositoryImpl struct {
    db *sql.DB
}

func (r *userRepositoryImpl) GetByID(id int) (*User, error) {
    // 데이터베이스 쿼리 로직
}

집계 관리

집계 루트는 전체 집계의 라이프사이클을 관리합니다.

type Order struct {
    ID      int
    Items   []OrderItem
    Status  string
}

func (o *Order) AddItem(item OrderItem) {
    o.Items = append(o.Items, item)
}

애플리케이션 서비스

애플리케이션 서비스는 도메인 로직을 캡슐화하여 외부 레이어가 도메인 객체를 직접 조작하는 것을 방지합니다.

type OrderService struct {
    repo OrderRepository
}

func (s *OrderService) CreateOrder(userID int, items []OrderItem) (*Order, error) {
    order := Order{UserID: userID, Items: items, Status: "Pending"}
    return s.repo.Save(order)
}

이벤트 기반

도메인 이벤트는 디커플링에 사용됩니다. Go에서는 채널 또는 Pub/Sub를 통해 이를 구현할 수 있습니다.

type OrderCreatedEvent struct {
    OrderID int
}

func publishEvent(event OrderCreatedEvent) {
    go func() {
        eventChannel <- event
    }()
}

CQRS (명령 쿼리 책임 분리) 결합

DDD는 CQRS와 결합할 수 있습니다. Go에서는 변경 작업에 명령을 사용하고 데이터 읽기에 쿼리를 사용할 수 있습니다.

type CreateOrderCommand struct {
    UserID int
    Items  []OrderItem
}

func (h *OrderHandler) Handle(cmd CreateOrderCommand) (*Order, error) {
    return h.service.CreateOrder(cmd.UserID, cmd.Items)
}

요약: MVC 대 DDD 아키텍처

아키텍처의 핵심 차이점

MVC 아키텍처

레이어: 세 개의 레이어—컨트롤러/서비스/DAO
책임:
- 컨트롤러는 요청을 처리하고 서비스는 로직을 포함합니다.
- DAO는 데이터베이스를 직접 조작합니다.
문제점: 서비스 레이어가 비대해지고 비즈니스 로직이 데이터 작업과 결합됩니다.

DDD 아키텍처

레이어: 네 개의 레이어—인터페이스 레이어 / 애플리케이션 레이어 / 도메인 레이어 / 인프라 레이어
책임:
- 애플리케이션 레이어는 프로세스를 조정합니다(예: 도메인 서비스 호출).
- 도메인 레이어는 비즈니스 원자적 작업을 캡슐화합니다(예: 주문 생성 규칙).
- 인프라 레이어는 기술 세부 사항을 구현합니다(예: 데이터베이스 액세스).
문제점: 도메인 레이어는 기술 구현과 독립적이며 로직은 레이어 구조와 밀접하게 대응합니다.

모듈성과 확장성

MVC:

높은 결합도: 명확한 비즈니스 경계가 부족합니다. 모듈 간 호출(예: 주문 서비스가 계정 테이블에 직접 의존)은 코드 유지 관리를 어렵게 만듭니다.
열악한 확장성: 새로운 기능을 추가하려면 전역 변경이 필요합니다(예: 위험 제어 규칙을 추가하려면 주문 서비스를 침해해야 함). 쉽게 계단식 문제가 발생합니다.

DDD:

제한된 컨텍스트: 모듈은 비즈니스 기능별로 나뉩니다(예: 결제 도메인, 위험 제어 도메인). 이벤트 기반 협업(예: 주문 결제 완료 이벤트)은 디커플링에 사용됩니다.
독립적인 진화: 각 도메인 모듈은 독립적으로 업그레이드할 수 있습니다(예: 결제 로직 최적화는 주문 서비스에 영향을 미치지 않음). 시스템 수준 위험을 줄입니다.

적용 가능한 시나리오

중소규모 시스템의 경우 MVC를 선호합니다. 단순한 비즈니스(예: 블로그, CMS, 관리 백엔드)는 명확한 비즈니스 규칙과 빈번한 변경 없이 빠른 개발이 필요합니다.
복잡한 비즈니스의 경우 DDD를 선호합니다. 규칙 집약적(예: 금융 거래, 공급망), 다중 도메인 협업(예: 전자 상거래 주문 및 재고 연결), 비즈니스 요구 사항의 잦은 변경.