프로젝트 구조화

새 프로젝트 만들기

lino project 명령어는 새로운 .NET 프로젝트를 간단하고 효율적으로 생성할 수 있게 도와줍니다. 이 명령어를 사용하면 프로젝트의 구조를 설정하고 필요한 의존성을 선택하며, 언어 및 인프라 설정을 할 수 있습니다.

새 프로젝트를 만들려면 다음 명령어를 사용하세요:

lino project new

실행 중에 CLI는 다음 정보를 요청합니다:

• 프로젝트 네임스페이스: 솔루션의 주요 네임스페이스를 정의합니다.
• 디스플레이 이름: 인터페이스에 표시되는 친숙한 이름입니다.
• 프로그래밍 언어: 현재 C# (.NET)만 지원됩니다.
• 개발 스택: 현재 .NET 9와 Aspire가 지원됩니다.
• 코드 분석기를 사용하시겠습니까? '예' 또는 '아니오'를 선택하세요.
• 분산 캐시를 사용하시겠습니까? '예' 또는 '아니오'를 선택하세요.
• 비동기 통신을 사용하시겠습니까? '예' 또는 '아니오'를 선택하세요.
• 데이터 언어: 시스템에서 사용되는 엔터티 이름과 다른 데이터의 언어를 정의합니다.
• 애플리케이션에서 지원하는 언어: 최대 10개 언어에 대해 국제화(i18n)를 지원합니다.
• 기본 언어: API, 응답 메시지, 유효성 검사 및 사용자 인터페이스에서 사용되는 기본 언어를 정의합니다.

정보를 확인한 후 Lino는 자동으로 프로젝트 구조를 생성합니다. 아래와 같습니다:

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   └── Services/
│       └── Shared/
│           ├── API/
│           │   └── MyApp.Shared.API.csproj
│           ├── Application/
│           │   └── MyApp.Shared.Application.csproj
│           ├── Domain/
│           │   └── MyApp.Shared.Domain.csproj
│           ├── Infrastructure/
│           │   └── MyApp.Shared.Infrastructure.csproj
│           └── Infrastructure.Persistence/
│               └── MyApp.Shared.Infrastructure.Persistence.csproj
└── tests/
    

코드 분석기

정적 코드 분석기는 개발 중에 코드의 품질과 일관성을 보장하는 데 도움이 되는 강력한 도구입니다. 이 도구는 실행 없이 소스 코드를 검사하여 오류, 스타일 문제 및 기타 불일치를 감지합니다.

프로젝트 생성 시 코드 분석기를 활성화하면, CLI가 자동으로 다음 패키지를 설정합니다:

• StyleCop.Analyzers: 코드 스타일 검사를 수행하여 들여쓰기, 공백 및 명명 규칙 등을 확인합니다.
• SonarAnalyzer.CSharp: 코드 품질 및 보안 규칙 집합으로, 일반적인 버그와 잠재적 취약점을 감지하는 데 도움을 줍니다.
• Roslynator.Analyzers: C# 코드에 대한 다양한 품질 규칙을 제공하여 리팩토링 및 최적화 기회를 식별합니다.

코드 분석기의 장점:

• 품질 향상: 코드를 깨끗하고 읽기 쉽게 유지하며 일반적인 문제를 방지합니다.
• 오류 예방: 실행 전에 오류를 감지하여 개발자가 문제를 조기에 수정할 수 있도록 돕습니다.
• 표준화: 모든 개발자가 동일한 규칙과 스타일을 따르도록 보장하여 코드 일관성을 향상시킵니다.
• 지원되는 리팩토링: 코드 리팩토링을 돕고 개선 사항에 대한 제안을 제공합니다.

코드 분석기를 활성화하면 코드 품질을 적극적으로 개선하고 프로덕션 환경에서 발생할 수 있는 오류를 줄일 수 있습니다.

분산 캐시

분산 캐시는 애플리케이션의 성능과 확장성을 향상시키는 기술로, 자주 액세스되는 데이터를 데이터베이스 외부의 캐시 계층에 저장합니다. 이를 통해 애플리케이션 인스턴스는 효율적으로 캐시 데이터를 공유하고, 고가용성 및 응답 시간을 줄일 수 있습니다.

프로젝트 생성 시 분산 캐시를 활성화하면 Redis가 Aspire 컨테이너에 통합되어 고가용성 캐시 시스템이 제공됩니다.

분산 캐시의 장점:

• 성능 향상: 요청 응답 시간을 줄여 데이터베이스 접근을 최소화합니다.
• 확장성: 분산 캐시 덕분에 애플리케이션은 수평 확장이 가능하며, 여러 인스턴스에서 투명하게 캐시를 접근할 수 있습니다.
• 고가용성: Redis를 사용하면 장애가 발생해도 캐시가 유지되며, 분산 시스템을 위한 강력한 솔루션을 제공합니다.
• 비용 절감: 데이터베이스와 시스템의 부하를 줄이고 반복되는 요청에서 발생하는 처리 부담을 줄입니다.

분산 캐시를 활성화하면 애플리케이션의 성능이 크게 향상되고, 사용자에게 빠른 응답을 제공하며, 백엔드 시스템의 부하를 줄일 수 있습니다.

비동기 통신

비동기 통신은 시스템과 구성 요소가 차단 없이 통신할 수 있는 접근 방식입니다. 즉, 데이터 전송이나 수신이 다른 작업의 처리를 방해하지 않습니다. 이는 분산 시스템이나 높은 부하에서 효율성과 회복력이 중요한 상황에서 특히 유용합니다.

비동기 통신을 활성화하면 RabbitMQ가 프로젝트에 통합되고, MassTransit가 설정되어 애플리케이션에서 비동기 통신을 쉽게 사용할 수 있습니다.

비동기 통신의 장점:

• 향상된 성능: 시스템의 실행 흐름을 차단하지 않고 작업을 병렬로 실행할 수 있습니다.
• 확장성: 시스템의 확장성을 용이하게 하여 대량의 데이터와 동시 사용자를 처리하면서 성능을 유지할 수 있습니다.
• 회복력: 일시적인 장애가 발생해도 비동기 통신을 통해 메시지를 재처리하거나 나중에 처리할 수 있습니다.
• 결합도 감소: 시스템이 즉각적인 응답을 필요로 하지 않고 통신할 수 있도록 설계되어 유연성과 조직력을 높입니다.

RabbitMQ와의 통합과 MassTransit 사용은 구성 요소 간의 통신을 더 효율적이고 회복력 있게 만들어 애플리케이션의 확장성과 유연성을 보장합니다.

다음 단계

이제 Lino로 .NET 프로젝트를 만들었으므로, 좋아하는 코드 편집기에서 프로젝트를 열어 보세요. Visual Studio, Visual Studio Code 또는 다른 IDE를 사용할 수 있습니다.

프로젝트를 열고 나면 애플리케이션을 구성하는 서비스를 추가하고 설정을 시작할 수 있습니다. 이것이 개발 흐름의 다음 단계입니다.

다음 섹션에서는 새로운 프로젝트 내에서 서비스를 생성하고 구성하는 방법을 보여 드리며, 애플리케이션의 요구 사항에 맞게 정리되고 확장 가능한 성장을 위한 준비를 합니다.

서비스 생성 및 관리

프로젝트를 생성한 후, 다음 단계는 서비스를 추가하는 것입니다. Lino는 모놀리식 시스템이나 마이크로서비스 아키텍처에서 사용할 수 있는 서비스를 간단하고 직관적인 방식으로 생성할 수 있는 방법을 제공합니다.

새 서비스를 생성하려면 다음 명령어를 사용하세요:

lino service new

실행 중에 CLI는 다음 정보를 요청합니다:

• 서비스 네임스페이스: 서비스의 이름과 네임스페이스를 정의합니다.
• 디스플레이 이름: 인터페이스에 표시되는 친숙한 이름입니다.
• 서비스 유형: 단순형 또는 모듈형 중 선택하세요.
• 데이터베이스: PostgreSQL 또는 SQL Server 중 선택하세요.

서비스 유형이 단순형인 경우, 다음과 같은 추가 정보도 요청됩니다:

• 아키텍처 스타일: 현재는 Clean Architecture만 지원됩니다.
• Strongly Typed ID 사용 여부? 예 또는 아니오 중에서 선택하세요.

서비스 유형

단순형 서비스: 단순형 서비스는 더 간결한 구조를 가지고 있으며, 모놀리식 시스템이나 각 서비스가 독립적인 책임을 가진 마이크로서비스 프로젝트에 적합합니다.

모듈형 서비스: 더 큰 시스템을 위해 더 나은 조직과 확장성이 필요한 경우, 모듈형 서비스를 선택할 수 있습니다. 이 유형은 서비스를 더 작고 구체적인 모듈로 나누어 시스템 유지보수 및 확장성을 용이하게 합니다.

단순형 서비스든 모듈형 서비스든 데이터베이스는 각 서비스마다 고유합니다. 아키텍처 및 Strongly Typed ID 사용 여부는 단순형 서비스에 적용됩니다. 모듈형 서비스의 경우, 이 결정은 서비스 내 각 모듈의 수준에서 내려집니다.

Lino의 구조는 유연하여 동일한 프로젝트 내에서 단순형 및 모듈형 서비스를 생성할 수 있습니다.

아키텍처 스타일

Lino는 모든 서비스에 Clean Architecture를 적용합니다. 이는 애플리케이션이 잘 구조화된 아키텍처를 따르도록 보장하며, 책임 분리를 촉진하고 유지보수 및 확장성을 용이하게 합니다.

Clean Architecture의 장점:

• 분리: 비즈니스 로직은 기술적 세부 사항과 독립적이므로 더 큰 유연성과 테스트 가능성을 제공합니다.
• 유지보수성: 레이어가 잘 분리되어 있어 다른 시스템 부분에 영향을 주지 않고 변경을 더 쉽게 할 수 있습니다.
• 테스트 가능성: 관심사의 분리가 각 레이어에 대한 유닛 및 통합 테스트를 독립적으로 작성하는 데 용이합니다.
• 확장성: 프로젝트는 더 쉽게 확장할 수 있습니다. 구성 요소는 비즈니스 로직에 영향을 주지 않고 변경되거나 교체될 수 있습니다.

만약 단순형 서비스를 선택하고 Clean Architecture 구현을 사용할 경우, 프로젝트는 다음과 같은 구조로 생성됩니다:

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   ├── Integrations/
│   │   └── Internal/
│   │       └── MySimpleService/
│   │           └── Http/
│   │               ├── Clients/
│   │               │   └── MyApp.Integrations.MySimpleService.Http.Clients.csproj
│   │               └── Contracts/
│   │                   └── MyApp.Integrations.MySimpleService.Http.Contracts.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MySimpleService/
│           ├── API/
│           │   └── MyApp.MySimpleService.API.csproj
│           ├── Application/
│           │   └── MyApp.MySimpleService.Application.csproj
│           ├── Domain/
│           │   └── MyApp.MySimpleService.Domain.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MySimpleService.Infrastructure.csproj
│           ├── Infrastructure.Persistence/
│           │   └── MyApp.MySimpleService.Infrastructure.Persistence.csproj
│           └── IntegrationEvents/
│               └── MyApp.MySimpleService.IntegrationEvents.csproj
└── tests/
    └── Services/
        └── MySimpleService/
            ├── IntegrationTests/
            │   └── MyApp.MySimpleService.IntegrationTests.csproj
            └── UnitTests/
                └── MyApp.MySimpleService.UnitTests.csproj
    

모듈형 서비스를 선택하면 프로젝트는 다음과 같은 구조를 채택하며, 개발 과정에서 새로운 모듈을 유연하고 체계적으로 추가할 수 있습니다:

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MyModularService/
│           ├── Host/
│           │   └── MyApp.MyModularService.Host.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MyModularService.Infrastructure.csproj
│           └── Modules/
└── tests/
    

Strongly Typed ID

Strongly Typed ID는 코드의 안전성과 명확성을 향상시키기 위한 접근 방식으로, 식별자(ID) 유형이 더 구체적이고 강력하게 타이핑되어, int 또는 guid와 같은 일반적인 유형을 사용하여 고유 엔터티를 나타내는 것을 방지합니다.

Strongly Typed ID를 사용하면, 예를 들어 사용자 ID를 나타내기 위해 일반적인 숫자 유형을 사용하는 대신 사용자 ID에 대한 구체적인 유형을 생성합니다. 이를 통해 서로 다른 유형의 ID가 잘못된 컨텍스트에서 사용되는 등의 오류를 방지할 수 있습니다.

Strongly Typed ID 사용의 장점:

• 타입 안전성: ID가 올바르게 사용되도록 보장하며, 예를 들어 사용자 ID와 제품 ID가 혼합되는 것을 방지합니다.
• 명확성: 각 ID 유형이 특정 클래스에 의해 명확하게 표현되어 코드가 더 명확해집니다.
• 리팩토링 용이성: 식별자 유형을 변경해야 할 경우, 특정 ID 유형만 변경하면 되며 나머지 코드는 안전하게 유지됩니다.
• 오류 방지: 잘못된 컨텍스트에서 일반적인 ID를 잘못 사용하는 버그를 줄입니다.

모듈형 서비스의 다음 단계

모듈형 서비스를 생성한 후, 다음 단계는 모듈을 추가하는 것입니다. 모듈을 사용하면 비즈니스 로직과 인프라를 독립적으로 구성할 수 있어 시스템을 더욱 확장 가능하고 조직적으로 만들 수 있습니다.

다음 섹션에서는 모듈형 서비스 내에서 모듈을 생성하고 관리하는 방법을 다룰 것입니다. 이를 통해 모듈형 서비스가 제공하는 유연성과 확장성을 최대한 활용할 수 있습니다.

모듈 생성 및 관리

모듈형 서비스를 만든 후, 다음 단계는 해당 서비스에 모듈을 추가하는 것입니다. 모듈은 비즈니스 로직을 독립적으로 구성할 수 있게 하여 시스템에 더 큰 확장성과 조직을 제공합니다.

새로운 모듈을 생성하려면 다음 명령어를 사용하세요:

lino module new

실행 중에 CLI는 다음 정보를 요청합니다:

• 서비스: 새로운 모듈이 생성될 서비스를 정의합니다.
• 모듈 네임스페이스: 모듈의 이름과 네임스페이스를 정의합니다.
• 디스플레이 이름: 인터페이스에 표시될 친숙한 이름입니다.
• 아키텍처 스타일: 현재는 Clean Architecture만 지원합니다.
• 강력하게 유형이 지정된 ID를 사용할까요? 예 또는 아니오를 선택하세요.

마지막으로, Lino는 모듈 서비스의 구조를 유지하면서 새로운 모듈을 생성합니다:

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   ├── Integrations/
│   │   └── Internal/
│   │       └── MyModularService/
│   │           └── MyModule/
│   │               └── Http/
│   │                   ├── Clients/
│   │                   │   └── MyApp.Integrations.MyModularService.MyModule.Http.Clients.csproj
│   │                   └── Contracts/
│   │                       └── MyApp.Integrations.MyModularService.MyModule.Http.Contracts.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MyModularService/
│           ├── Host/
│           │   └── MyApp.MyModularService.Host.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MyModularService.Infrastructure.csproj
│           └── Modules/
│               └── MyModule/
│                   ├── API/
│                   │   └── MyApp.MyModularService.MyModule.API.csproj
│                   ├── Application/
│                   │   └── MyApp.MyModularService.MyModule.Application.csproj
│                   ├── Domain/
│                   │   └── MyApp.MyModularService.MyModule.Domain.csproj
│                   ├── Infrastructure/
│                   │   └── MyApp.MyModularService.MyModule.Infrastructure.csproj
│                   ├── Infrastructure.Persistence/
│                   │   └── MyApp.MyModularService.MyModule.Infrastructure.Persistence.csproj
│                   └── IntegrationEvents/
│                       └── MyApp.MyModularService.MyModule.IntegrationEvents.csproj
└── tests/
    └── Services/
        └── MyModularService/
            └── Modules/
                └── MyModule/
                    ├── IntegrationTests/
                    │   └── MyApp.MyModularService.MyModule.IntegrationTests.csproj
                    └── UnitTests/
                        └── MyApp.MyModularService.MyModule.UnitTests.csproj

데이터베이스 구조

데이터베이스는 서비스와 연결되어 있음을 강조하는 것이 중요합니다. 모듈형 서비스 내에서 각 모듈은 관련된 데이터베이스 내에서 고유한 스키마로 표현됩니다. 이 접근 방식은 여러 개의 데이터베이스를 생성할 필요 없이 격리와 구성을 제공합니다.

모듈 간 독립성에 대해

서비스 간에는 직접적인 의존성이 없듯이, 모듈도 서비스 내에서 독립적인 프로젝트로 생성됩니다.

이 분리의 장점:

• 격리: 각 모듈은 독립적으로 발전할 수 있어 유지 관리와 지속적인 발전이 용이합니다.
• 조직화: 애플리케이션은 진정으로 모듈화되며, 경계를 지키고(Bounded Contexts) 소프트웨어 아키텍처의 모범 사례를 촉진합니다.
• 유연성: 서비스를 구성하는 다른 모듈에 직접적인 영향을 미치지 않고 모듈을 추가, 제거 또는 리팩토링할 수 있습니다.
• 테스트 용이성: 각 모듈은 독립적으로 테스트할 수 있어 시스템의 신뢰성 및 품질이 향상됩니다.

이로써 모듈 생성 프로세스가 완료되었습니다. 다음 주제에서는 모듈의 내부 요소들(엔티티, 값 객체, 열거형, 명령어, 쿼리, API, 통합 등)을 어떻게 구조화할지에 대해 다룰 것입니다.