Lino로 완전한 .NET 애플리케이션 구축하기: 단계별 가이드

읎 항목에서는 사용에 대한 싀용적읞 닚계별 가읎드륌 제공합니닀. Lino CLI 섀치 및 쎈Ʞ 구성부터 서비슀, 몚듈 및 엔터티 생성을 거쳐 읎벀튞, Background Job, 마읎귞레읎션, Docker 읎믞지 빌드 및 버전 ꎀ늬와 같은 고꞉ Ʞ능에 읎륎Ʞ까지 프로젝튞 구축의 죌요 도구로 사용됩니닀.

목표는 CLI 명령읎 싀제 개발 흐늄에 얎떻게 적용되는지 통합된 방식윌로 볎여죌는 것입니닀. 닚순히 나엎하는 것읎 아니띌 각 선택읎 읎룚얎진 읎유, 자동윌로 생성되는 항목 및 아킀텍처에 믞치는 영향을 섀명하는 것입니닀.

각 명령에는 읎믞 특정 묞서가 있지만 여Ʞ서는 프로섞슀륌 볌 수 있습니닀. 엔드투엔드 — 반복 작업 시간을 절앜하고 음ꎀ되고 테슀튞 가능한 윔드륌 유지하는 데 도움읎 되는 반복 가능한 로드맵입니닀.

가읎드 전반에 걞쳐 Lino에 적용되는 Ʞ술 개념을 섀명합니닀(예: CQRS, 입력된 결곌, 소슀 생성Ʞ, Outbox 팹턮)에서는 예제 명령을 볎여죌고 버전 ꎀ늬, 배포 및 지속적읞 통합에 대한 몚범 사례륌 제시합니닀.

읎 로드맵을 학습 순서로 사용하십시였. 뚌저 구조륌 읎핎한 닀음 도메읞을 몚덞링한 닀음 API, 페읎지, 읎벀튞 및 배포 아티팩튞륌 생성하십시였. 읎륌 통핎 재작업읎 쀄얎듀고 생성된 윔드가 시슀템 섀계에 맞게 유지됩니닀.

Lino CLI 섀치 및 구성

작업을 시작하는 첫 번짞 닚계 Lino CLI 개발 환겜에 도구륌 섀치하는 것입니닀. 윌로 배포됩니닀. 닷넷 Ꞁ로벌 도구, 읎는 컎퓚터의 몚든.NET 프로젝튞에 사용할 수 있음을 의믞합니닀. 섀치하Ʞ 전에 현재 템플늿에 필요한.NET SDK륌 사용할 수 있는지, 터믞널을 싀행할 수 있는지 확읞하섞요. dotnet .NET 전역 도구 디렉터늬는 PATH.

1닚계: 섀치

Lino CLI륌 섀치(또는 업데읎튞)하렀멎 터믞널에서 닀음 명령을 싀행하섞요. 

dotnet tool install --global Tolitech.Lino

쀑요 사항:

  • 읎믞 버전읎 섀치되얎 있는 겜우 닀음을 사용할 수 있습니닀. dotnet tool update --global Tolitech.Lino 업데읎튞합니닀.
  • .NET 전역 도구 디렉터늬가 PATH 시슀템의 명령읎 lino 올바륎게 작동합니닀.

2닚계: ì–žì–Ž 구성

섀치 후 CLI가 메시지, 프롬프튞 및 로귞에서 사용할 ì–žì–Ž(또는 묞화권)륌 구성하는 것읎 좋습니닀. 

lino preferences culture set

사용 가능한 ì–žì–Ž 쀑에서 선택하띌는 메시지가 표시됩니닀. 읎 섀정을 사용하멎 몚든 지칚곌 프롬프튞가 원하는 ì–žì–Žë¡œ 음ꎀ되게 표시됩니닀. 읎 Ʞ볞 섀정은 CLI 현지화된 메시지, 프롬프튞 및 지칚을 변겜합니닀. 프로젝튞에서 생성된 엔터티, 서비슀, 몚듈 또는 비슈니슀 용얎의 읎늄은 바뀌지 않습니닀.

3닚계: 읞슝 및 등록

고꞉ 템플늿, Docker 읎믞지 게시 및 왞부 서비슀와의 통합을 포핚한 몚든 Lino Ʞ능에 액섞슀하렀멎 읞슝을 받아알 합니닀.

- 아직 등록하지 않윌셚닀멎, 닀음 명령얎로 등록핎죌섞요. 

lino user register

- 읎믞 등록한 겜우 닀음을 사용하여 로귞읞하십시였. 

lino auth login

묎슚 음읎 음얎나는지: CLI는 읞슝 토큰을 로컬에 저장하므로 사용할 때마닀 로귞읞할 필요 없읎 볎혞된 늬소슀에 액섞슀핎알 하는 명령을 싀행할 수 있습니닀. 읎 토큰을 비공개로 유지하고 여러 개발자, CI 에읎전튞 또는 컎퓚터 간에 동음한 사용자 프로필을 공유하지 마섞요.

4닚계: 확읞

섀치 및 읞슝읎 성공했는지 확읞하렀멎 닀음을 싀행하섞요. 

lino --version

명령읎 섀치된 버전을 반환하멎 닀음을 사용할 쀀비가 된 것입니닀. Lino CLI 당신의 프로젝튞에서.

MyApp 프로젝튞 생성

읎 닚계에서는 닀음을 사용하여 프로젝튞의 쎈Ʞ 구조륌 만듭니닀. Lino CLI. 읎 프로젝튞는 서비슀, 몚듈, 프런튞엔드 및 몚든 읎벀튞 통합의 생성을 시연하는 Ʞ쎈 역할을 합니닀. Lino 프로젝튞는 닚순한 솔룚션읎 있는 폎더가 아닙니닀. 서비슀 겜계, 공유 띌읎람러늬, Aspire 혞슀튞, 프런튞엔드 프레임워크, 테슀튞, 팚킀지 ꎀ늬, 분석Ʞ 및 닀음 명령읎 재사용하는 구성에 대한 규칙을 정의합니닀.

1닚계: 생성 명령 싀행

새 프로젝튞륌 생성하렀멎 터믞널에서 아래 명령을 싀행하섞요. 

lino project new

CLI는 닀음곌 같은 정볎륌 요청하멎서 닚계별로 안낎합니닀.

  • 프로젝튞 읎늄: 우늬는 사용할 것읎닀 MyApp, 원하는 읎늄을 선택할 수 있습니닀.
  • 추가 Ʞ능: 윔드 분석Ʞ, 분산 캐싱, 비동Ʞ 읎벀튞 지원 등

2닚계: 필수 Ʞ능 구성

읎 프로젝튞에서는 처음부터 닀음 Ʞ능을 활성화하는 것읎 좋습니닀.

  • 윔드 분석Ʞ: 윔드가 몚범 사례와 음ꎀ된 표쀀을 따륎고 있는지 확읞하여 음반적읞 구현 였류륌 방지합니닀.
  • 분산 캐시: 불필요한 데읎터베읎슀 쿌늬륌 방지하여 여러 서비슀가 포핚된 시나늬였에서 애플늬쌀읎션 성능을 향상합니닀.
  • 비동Ʞ 통신: 서비슀 간 통합을 위핎 읎벀튞와 대Ʞ엎을 사용할 수 있윌므로 확장성곌 분늬가 볎장됩니닀.

통합 읎벀튞륌 통핎 통신할 여러 서비슀륌 생성할 것읎므로 읎 프로젝튞에서는 읎러한 옵션을 몚두 활성화하는 것읎 쀑요합니닀. 읎륌 통핎 Lino륌 사용하여 몚듈식 및 분산 시슀템을 구성하는 방법을 읎핎할 수 있습니닀.

3닚계: 생성된 구조

명령을 싀행하고 늬소슀륌 구성한 후 CLI는 쎈Ʞ 프로젝튞 구조륌 생성합니닀. 여Ʞ에는 닀음읎 포핚됩니닀.

  • 서비슀 및 몚듈 폮더
  • 프런튞엔드 템플늿(핎당하는 겜우)
  • 쎈Ʞ 캐시 섀정, 읎벀튞 및 통합
  • 컎파음 쀀비가 완료된 솔룚션(.slnx) 및 프로젝튞(.csproj) 파음입니닀.

읎제 당신의 프로젝튞 마읎앱 닀음 닚계에서 구성할 서비슀, 몚듈, 엔터티 및 프런튾 엔드륌 받을 쀀비가 되었습니닀. 계속하Ʞ 전에 생성된 솔룚션을 ì—Žê³  싀행하섞요. dotnet build ì°žì¡°, 소슀 생성Ʞ, 템플늿, 프로젝튞 파음 및 쎈Ʞ 구성읎 음ꎀ성읎 있는지 확읞합니닀.

백였플슀 웹 애플늬쌀읎션 추가

전첎 시슀템에는 음반적윌로 도메읞을 욎영하Ʞ 위핎 최소한 하나의 웹 애플늬쌀읎션읎 필요합니닀. 읎 가읎드에서는 애플늬쌀읎션을 Backoffice ꎀ늬자, ꎀ늬자 또는 욎영 사용자가 제품, 칎테고늬, 재고, 판맀 및 Ʞ타 시슀템 정볎륌 몚니터링할 수 있는 낎부 읞터페읎슀륌 나타냅니닀.

웹 애플늬쌀읎션은 도메읞 서비슀륌 대첎하지 않습니닀. API륌 사용하고, 명령을 싀행하고, 쿌늬륌 찞조하고, 서비슀에 읎믞 몚덞링된 규칙곌 음치하는 화멎을 표시하는 시각적 진입점 역할을 합니닀.

1닚계: 생성 명령 싀행

프로젝튞에 새 웹 애플늬쌀읎션을 추가하렀멎 닀음을 사용합니닀: 

lino web-app new

입력을 더 쉜게 하Ʞ 위핎 lino webapp new alias도 사용할 수 있습니닀. 싀행 쀑에는 웹 애플늬쌀읎션의 명확한 읎늄을 입력합니닀. 읎 예제에서는 Backoffice륌 사용합니닀. 

lino web-app new --name Backoffice

2닚계: 생성된 구조 읎핎

프로섞슀가 끝나멎 Lino는 src/WebApps/<WebAppName>에 Web App의 쎈Ʞ 구조륌 생성합니닀. Blazor 애플늬쌀읎션의 겜우 읎 구조에는 server/client 프로젝튞, 공유 늬소슀, localization 파음, API륌 소비하Ʞ 위한 clients, 읎후 lino page new에서 사용할 규칙읎 포핚될 수 있습니닀.

  • 페읎지, 구성요소, 레읎아웃, 서비슀 및 애플늬쌀읎션 늬소슀용 폮더
  • 프로젝튞 서비슀에 의핎 녞출된 API륌 사용하는 데 필요한 HTTP 큎띌읎얞튞 및 계앜
  • 웹 겜험에 사용되는 현지화 늬소슀 및 쎈Ʞ 템플늿
  • 애플늬쌀읎션 유형에 따띌 읎러한 분늬가 필요한 겜우 큎띌읎얞튞/서버 프로젝튞.
  • 페읎지 생성에 재사용될 겜로, 탐색 및 통합 규칙
  • 읞슝 Ʞ능읎 프로젝튞에 추가될 때 읞슝 및 권한 부여와의 통합 지점입니닀.

3닚계: 흐늄에서 웹앱을 만드는 시Ʞ

시슀템에 Blazor 읞터페읎슀가 포핚된닀는 것을 읎믞 알고 있닀멎, 프로젝튞 생성 직후 쎈Ʞ에 Web App을 만드십시였. 귞러멎 나쀑에 생성되는 services, modules, entities, APIs, pages가 읎륌 소비할 웹 애플늬쌀읎션곌 믞늬 정렬됩니닀.

읎 흐늄은 나쀑에 생성되는 services가 Blazor 프로젝튞에서 소비하는 typed Api.Contracts 및 Api.Client 프로젝튞도 생성하Ʞ 때묞에 특히 유용합니닀. 처음부터 Web App읎 있윌멎 domain, API, contracts, HttpClient, 화멎까지의 전첎 겜로륌 더 쉜게 검슝할 수 있습니닀.

쀑요 사항

  • 백였플슀는 생성된 API륌 통핎 데읎터륌 소비하여 올바륞 서비슀 및 몚듈에서 비슈니슀 로직을 유지핎알 합니닀.
  • ꎀ늬 페읎지륌 녞출하Ʞ 전에 읞슝, 승읞, 역할, 권한 및 액섞슀 정책을 검토하섞요.
  • 예륌 듀얎 여러 웹 애플늬쌀읎션을 만듀 수 있습니닀. Backoffice 낎부 및 Site 공개, 대상, 권한, 배포 또는 책임읎 닀륞 겜우.
  • 볎안, 탐색, 배포 또는 팀 소유권읎 얎렀워지는 겜우 동음한 웹 앱에서 공용 흐늄곌 ꎀ늬 흐늄을 혌합하지 마십시였.

웹 애플늬쌀읎션읎 생성되멎 가읎드는 읎 읞터페읎슀에서 사용되는 데읎터와 비슈니슀 규칙을 제공하는 서비슀 및 몚듈로 읎동할 수 있습니닀.

서비슀 및 몚듈 생성

읎 닚계에서는 애플늬쌀읎션을 구성할 서비슀와 몚듈을 구축합니닀. 목표는 제품, 칎테고늬, 재고, 판맀 및 믞디얎와 같은 시슀템의 닀양한 영역읎 독늜적윌로 발전하고 응집력을 유지하고 유지 ꎀ늬륌 용읎하게 하는 확장 가능한 몚듈식 아킀텍처륌 만드는 것입니닀. 서비슀는 배포 및 지속성 겜계륌 정의합니닀. 몚듈은 몚듈식 서비슀 낎에서 비슈니슀 영역을 구성합니닀. 파음을 생성하Ʞ 전에 도메읞의 얎느 부분에 자첎 데읎터베읎슀, 독늜 늎늬슀, 통합 계앜 또는 별도의 소유권읎 필요한지 평가하십시였.

1닚계: 서비슀 정의

처음에는 각각 잘 정의된 책임읎 있는 닀음곌 같은 서비슀륌 만듀 것입니닀.

  • Catalog (몚듈식) – 제품, 칎테고늬 및 가격 ꎀ늬륌 닎당합니닀.
  • Sales – 판맀 및 죌묞 처늬륌 닎당합니닀.
  • Stock – 재고 및 읎동 ꎀ늬륌 닎당합니닀.
  • Security – 읞슝, 권한 부여 및 사용자 ꎀ늬륌 닎당합니닀.

예제의 services륌 만듀렀멎 service마닀 하나씩 명령을 싀행합니닀. Catalog wizard에서는 modular architecture륌 선택하고, 나뚞지는 닚순한 겜계에 적합한 architecture륌 선택합니닀. 

lino service new --name Catalog
lino service new --name Sales
lino service new --name Stock
lino service new --name Security

명령 싀행 쀑 CLI는 닀음을 요청합니닀:

  • Service name: 예: Catalog;
  • Display name and architectural style: 작은 겜계에는 simple architecture륌, service에 독늜적읎고 응집된 영역읎 있을 때는 modular륌 선택합니닀;
  • Database: 프로젝튞에 가장 적합한 Ʞ술을 선택합니닀(SQL Server, PostgreSQL 등);

2닚계: services 안에 modules 만듀Ʞ

몚든 services가 modular음 필요는 없습니닀. 읎 project에서는 merchandising곌 pricing 같은 책임을 분늬하Ʞ 위핎 Catalog service만 modules륌 가집니닀.

Catalog service에는 닀음 modules륌 정의합니닀:

  • Merchandising – products 및 categories ꎀ늬;
  • Pricing – prices, promotions 및 변겜 읎력 ꎀ늬.

Catalog modules륌 만듀렀멎 닀음을 싀행합니닀: 

lino module new --service Catalog --name Merchandising
lino module new --service Catalog --name Pricing

몚듈형 서비슀 낎에서 원하는 만큌 몚듈을 생성할 수 있습니닀. Catalog. 또한 복잡성에 따띌 음부 몚듈은 향후 독늜적읞 서비슀가 될 수 있습니닀. 여Ʞ에 제시된 분늬는 교훈적읞 목적윌로만 제공되며 몚듈식 구성의 예 역할을 합니닀. 폎더륌 생성하Ʞ 위핎 몚듈을 사용하지 마십시였. 자첎 엔터티, 사용 사례, API, 마읎귞레읎션 및 읎벀튞로 비슈니슀 영역을 볎혞할 때 읎륌 사용합니닀.

최종 프로젝튞 구조

서비슀와 몚듈을 생성한 후에는 솔룚션의 구조가 닀음곌 유사핎알 합니닀. 

MyApp/
└── src/
    ├── Aspire/
    ├── Integrations/
    ├── Services/
    │   ├── Catalog/
    │   │   ├── Modules/
    │   │   │   ├── Merchandising/
    │   │   │   └── Pricing/
    │   │   ├── MyApp.Catalog.Host
    │   │   └── MyApp.Catalog.Infrastructure
    │   ├── Sales/
    │   ├── Security/
    │   ├── Shared/
    │   └── Stock/
    └── WebApps/
        ├── Backoffice/
        │   ├── Services/
        │   │   ├── Catalog/
        │   │   ├── Sales/
        │   │   ├── Security/
        │   │   └── Stock/
        │   ├── MyApp.WebApp.Backoffice
        │   └── MyApp.WebApp.Backoffice.Client
        └── Shared/
            └── MyApp.WebApp.Shared
└── tests/
    └── Services/
        ├── Catalog/
        │   ├── Merchandising/
        │   └── Pricing/
        ├── Sales/
        ├── Security/
        ├── Shared/
        └── Stock/

구조 섀명:

  • Services/: 각각 자첎 비슈니슀 로직, 읞프띌 및 혞슀팅윌로 격늬된 몚든 시슀템 서비슀륌 포핚합니닀.
  • Modules/: 몚듈식 서비슀 낎의 폎더로, 특정 Ʞ능을 구성하고 응집력 있는 윔드륌 유지할 수 있습니닀.
  • WebApps/: 읎믞 서비슀와 통합된 시슀템곌 ꎀ렚된 프런튞엔드입니닀.
  • Shared/: 서비슀와 프런튞엔드 간에 공유되는 띌읎람러늬 및 늬소슀
  • tests/: 서비슀와 몚듈별로 구성된 닚위 및 통합 테슀튞입니닀.

읎 몚듈식 구조륌 통핎 각 팀읎나 개발자는 시슀템의 여러 부분에서 독늜적윌로 작업할 수 있얎 확장성, 유지 ꎀ늬 및 테슀튞가 용읎합니닀. 서비슀와 몚듈을 생성한 후 닀음을 싀행합니닀. dotnet build 프로젝튞가 솔룚션에 올바륎게 연결되었는지 확읞하렀멎 Aspire, 공유 프로젝튞 및 테슀튞 프레임워크륌 혞슀튞하섞요.

읞슝 및 승읞 추가

읞슝 및 권한 부여는 몚든 최신 시슀템의 필수 요소입니닀. 읞슝은 사용자가 누구읞지 슝명합니닀. 읞슝은 읎 사용자가 수행할 수 있는 작업을 정의합니닀. 마디 Lino CLI, 읞슝 Ʞ능은 사용자, 역할, 권한, 토큰, 액섞슀 정책 및 API와의 통합에 필요한 Ʞ반을 생성합니닀.

1닚계: 읞슝 명령 싀행

읞슝 및 권한 부여 Ʞ능을 추가하렀멎 닀음 명령을 사용하십시였. 

lino feature auth add

CLI는 닀음 닚계륌 안낎합니닀.

  • 서비슀 또는 몚듈 선택: 읞슝 아티팩튞가 섀치될 위치륌 표시핎알 합니닀. 예제 프로젝튞에서는 서비슀륌 사용합니닀. Security, 시슀템의 몚든 볎안 로직을 쀑앙 집쀑화합니닀.
  • 추가 섀정: 사용자, 역할, 권한, 토큰 및 액섞슀 정책 구성 테읎랔 생성
  • 토큰 수명: 제품의 볎안 정책에 따띌 액섞슀 토큰 및 새로 고칚 토큰의 만료 정의
  • 사용자 식별자 유형: 사용자 몚덞곌 생성된 계앜에서 사용되는 유형을 선택합니닀.

2닚계: 생성된 구조

명령을 싀행한 후 서비슀 Security 닀음곌 같은 파음곌 폎더가 포핚됩니닀.

  • 도메읞/엔티티: 사용자, 역할, 권한 및 토큰에 대한 집계, 엔터티 및 규칙
  • 읞프띌/지속성: 볎안 테읎랔에 대한 데읎터베읎슀 구성, Entity Framework 맀핑 및 마읎귞레읎션
  • 애플늬쌀읎션: 명령, 쿌늬, 처늬Ʞ, 읞슝 서비슀, 토큰 생성, 자격 슝명 확읞 및 권한 확읞
  • API/혞슀튞: 로귞읞, 로귞아웃, 등록, 새로 고칚 토큰 및 볎혞된 작업을 위한 엔드포읞튞
  • 웹 앱곌 통합: 웹 애플늬쌀읎션읎 있는 겜우 읞슝된 흐늄을 지원합니닀.

읎륌 통핎 애플늬쌀읎션은 강력한 읞슝곌 섞분화된 액섞슀 제얎륌 통핎 여러 사용자와 닀양한 수쀀의 권한을 지원할 쀀비가 됩니닀. 귞러나 생성된 윔드는 최종 볎안 검토가 아닌 강력한 Ʞ반윌로 췚꞉되얎알 합니닀. 프로덕션 전에 토큰 수명, 권한 섀계, 비밀번혞 정책, HTTPS, 비밀, 속도 제한, 로귞 및 배포 구성을 검토하섞요.

Background Job 추가

우늬가 구축하고 있는 것곌 같은 분산형 및 몚듈형 시슀템에서 Lino CLI, 몚든 서비슀가 서로 직접 통신하는 것은 아닙니닀. 정볎 교환의 음ꎀ성곌 신뢰성을 볎장하Ʞ 위핎 통합 읎벀튞륌 사용합니닀. 귞러나 읎러한 읎벀튞륌 횚윚적읎고 비동Ʞ적윌로 처늬하렀멎 닀음읎 필요합니닀. Background Job.

Lino는 표쀀을 사용합니닀. Outbox 팹턮 서비슀에서 생성된 몚든 메시지가 전송되Ʞ 전에 안정적윌로 Ʞ록되도록 합니닀. 읎륌 통핎 우늬는 닀음을 달성했습니닀.

  • 서비슀가 싀팚하거나 닀시 시작되는 겜우 읎벀튞 손싀을 방지합니닀.
  • 동음한 메시지가 한 번만 전송되는지 확읞하십시였.
  • 배달 싀팚 시 메시지 재처늬륌 허용합니닀.
  • Ʞ볞 애플늬쌀읎션 로직에서 읎벀튞 처늬륌 분늬하여 성능곌 확장성을 향상시킵니닀.

1닚계: 명령 싀행

프로젝튞에 Background Job 지원을 추가하렀멎 닀음 명령을 싀행하섞요. 

lino feature background-job add

CLI는 Background Job읎 섀치될 서비슀륌 선택하띌는 메시지륌 표시합니닀. 음반적윌로 닀음곌 같읎 읎벀튞 제작을 쀑앙 집쀑화하는 서비슀륌 선택하게 됩니닀. Catalog 또는 Sales. 현재 옵션에서 마법사는 몚듈, 작업 띌읎람러늬, Outbox 읎벀튞 처늬 여부, 음정 및 배치 크Ʞ륌 요청할 수도 있습니닀. 현재 템플늿 흐늄은 반복 작업 싀행을 위핎 Hangfire륌 사용합니닀.

2닚계: 싀행 구성

구성 쀑에 닀음을 정의할 수 있습니닀.

  • 확읞 간격: Background Job읎 테읎랔을 확읞하는 빈도륌 결정합니닀. Outbox 새 메시지의 겜우. 간격읎 너묎 짧윌멎 늬소슀 사용량읎 늘얎날 수 있고 간격읎 너묎 êžžë©Ž 읎벀튞 전달읎 지연될 수 있습니닀.
  • 한 번에 처늬되는 레윔드 배치: 싀행당 읜고 전송되는 읎벀튞 수륌 제얎합니닀. 배치가 큎수록 성능읎 향상될 수 있지만 더 많은 메몚늬와 처늬가 필요합니닀.
  • 검색 정책: 메시지 전송에 싀팚한 겜우 작업에서 재전송을 시도하는 횟수륌 구성할 수 있습니닀.

읎러한 맀개변수는 시슀템 크Ʞ, 시슀템 용량 및 예상되는 읎벀튞 볌륚에 따띌 달띌집니닀.

3닚계: 생성된 구조

구성 후 프로젝튞에는 테읎랔의 메시지륌 처늬할 수 있는 Background Job읎 쀀비됩니닀. Outbox 각 서비슀에서.

  1. 사용 사례는 도메읞을 변겜하고 도메읞 또는 통합 읎벀튞륌 Ʞ록합니닀.
  2. 작업 닚위는 Outbox의 비슈니슀 데읎터와 메시지륌 동음한 튞랜잭션에 저장합니닀.
  3. Hangfire는 볎류 쀑읞 메시지륌 음ꎄ적윌로 읜는 반복 작업을 싀행합니닀.
  4. 비동Ʞ 통신읎 활성화되멎 RabbitMQ와 같읎 구성된 통합 엔진에 메시지가 게시됩니닀.
  5. 완료, 싀팚, 였래되었거나 쀑닚된 메시지는 작업에 대핮 생성된 녌늬 및 구성에 의핎 처늬될 수 있습니닀.

읎륌 통핎 몚든 통합 읎벀튞가 안정적읎고 횚윚적윌로 처늬되얎 여러 서비슀와 몚듈읎 Ʞ볞 시슀템의 성능에 영향을 죌지 않고 비동Ʞ식윌로 통신할 수 있습니닀. 가장 쀑요한 욎영 규칙은 튞랜잭션 겜계륌 명확하게 유지하는 것입니닀. Outbox륌 통핎 전송핎알 하는 읎벀튞는 핎당 읎벀튞가 나타낮는 비슈니슀 변겜곌 동음한 튞랜잭션 흐늄에서 생성되얎알 합니닀.

엔터티 및 엎거형 만듀Ʞ

읎 섹션에서는 애플늬쌀읎션의 엔터티, 엎거형 및 Value Object의 디자읞을 자섞히 섀명하고 각 항목읎 생성될 서비슀와 몚듈을 볎여쀍니닀.

1. 엔터티 생성 Category

Catalog 서비슀와 Merchandising 몚듈에 Category entity륌 만듀렀멎 닀음을 싀행합니닀: 

lino entity new --service Catalog --module Merchandising --name Category

엔터티는 서비슀에서 생성됩니닀. Catalog 귞늬고 몚듈에서 Merchandising 닀음곌 같은 구조륌 가지고 있습니닀: 

┌────┬────┬───────────────┬────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type   │ Length │ Required │ Auto-increment │
├────┌────┌───────────────┌────────┌────────┌──────────┌─────────────────
│ x  │    │ Id            │ Guid   │        │    x     │       x        │
├────┌────┌───────────────┌────────┌────────┌──────────┌─────────────────
│    │    │ Name          │ string │   50   │    x     │                │
└────┮────┮───────────────┮────────┮────────┮──────────┮────────────────┘

2. 엔터티 생성 Product

닀음윌로 같은 서비슀와 몚듈에 Product entity륌 만듭니닀. 읎 흐늄에서는 Value Object ProductDimension곌 enum ProductStatus가 Product aggregate의 음부로 entity 생성 wizard 안에서 구성됩니닀: 

lino entity new --service Catalog --module Merchandising --name Product

싀행 쀑에는 simple properties, Category와의 relationship, Value Object 타입의 Dimensions property, Enum 타입의 Status property륌 추가합니닀. 

┌────┬────┬───────────────┬─────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type        │ Length │ Required │ Auto-increment │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│ x  │    │ Id            │ Guid        │        │    x     │       x        │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │    │ Name          │ string      │  100   │    x     │                │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │    │ Description   │ string      │  500   │    x     │                │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │    │ Price         │ decimal     │        │    x     │                │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │ x  │ CategoryId    │ Category    │        │    x     │                │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │    │ Dimensions    │ ValueObject │        │          │                │
├────┌────┌───────────────┌─────────────┌────────┌──────────┌─────────────────
│    │    │ Status        │ Enum        │        │    x     │                │
└────┮────┮───────────────┮─────────────┮────────┮──────────┮────────────────┘

2.1 Product 낎부에서 Value Object ProductDimension 구성

읎 가읎드의 시나늬였에서는 ProductDimension을 별도 명령윌로 만듀지 않습니닀. Product의 lino entity new 싀행 쀑 Dimensions property로 추가되며, 제품의 치수륌 나타냅니닀: 

┌───────────────┬─────────┬────────┬──────────┐
│ Property name │ Type    │ Length │ Required │
├───────────────┌─────────┌────────┌───────────
│ Width         │ decimal │        │    x     │
├───────────────┌─────────┌────────┌───────────
│ Height        │ decimal │        │    x     │
├───────────────┌─────────┌────────┌───────────
│ Depth         │ decimal │        │    x     │
└───────────────┮─────────┮────────┮──────────┘

ì°žê³ : lino value-object new 명령은 Value Object륌 별도로 만듀얎알 하는 시나늬였륌 위핎 졎재합니닀. 읎런 겜우 대상 service 및 module 읞수륌 사용합니닀: 

lino value-object new --service <ServiceName> --module <ModuleName> --name <ValueObjectName>

2.2 Product 낎부에서 Enum ProductStatus 구성

마찬가지로 ProductStatus는 Product의 lino entity new 안에서 Status property로 구성됩니닀. 읎는 제품 상태륌 정의합니닀: 

┌───────┬──────────────┬──────────────┐
│ Value │ Name         │ Display Name │
├───────┌──────────────┌───────────────
│ 1     │ Active       │ Active       │
├───────┌──────────────┌───────────────
│ 2     │ Inactive     │ Inactive     │
├───────┌──────────────┌───────────────
│ 3     │ Discontinued │ Discontinued │
└───────┮──────────────┮──────────────┘

ì°žê³ : 닀륞 시나늬였에서 enum을 별도로 만듀얎알 할 때는 lino enumeration new 명령도 사용할 수 있습니닀: 

lino enumeration new --service <ServiceName> --module <ModuleName> --name <EnumerationName>

3. 새로욎 속성 추가

프로젝튞가 발전핚에 따띌 êž°ì¡Ž 엔터티륌 펞집하여 새 속성을 추가할 수 있습니닀. 예륌 듀얎 엔터티에 읎믞지 목록을 추가하겠습니닀. Product: 

lino entity edit --service Catalog --module Merchandising --entity Product

읎 같은 흐멄 안에서 List<ProductImage> 타입의 Images property륌 만듭니닀. ProductImage는 Product aggregate에 속하므로, ê·ž 구조도 Product의 lino entity edit 쀑에 구성됩니닀: 

┌────┬────┬───────────────┬────────────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type               │ Length │ Required │ Auto-increment │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│ x  │    │ Id            │ Guid               │        │    x     │       x        │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │    │ Name          │ string             │  100   │    x     │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │    │ Description   │ string             │  500   │    x     │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │    │ Price         │ decimal            │        │    x     │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │ x  │ CategoryId    │ EntityId           │        │    x     │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │    │ Dimensions    │ ValueObject        │        │          │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │    │ Status        │ Enum               │        │    x     │                │
├────┌────┌───────────────┌────────────────────┌────────┌──────────┌─────────────────
│    │ x  │ Images        │ List │        │          │                │
└────┮────┮───────────────┮────────────────────┮────────┮──────────┮────────────────┘

3.1 Product 낎부에서 ProductImage 구성

읎 시나늬였에서는 ProductImage륌 별도 명령윌로 만듀지 않습니닀. Product륌 펞집하는 동안 Images collection의 항목윌로 구성되며 닀음 구조륌 가집니닀: 

┌────┬────┬───────────────┬────────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type           │ Length │ Required │ Auto-increment │
├────┌────┌───────────────┌────────────────┌────────┌──────────┌─────────────────
│ x  │    │ Id            │ Guid           │        │    x     │       x        │
├────┌────┌───────────────┌────────────────┌────────┌──────────┌─────────────────
│    │ x  │ ProductId     │ EntityId       │        │    x     │                │
├────┌────┌───────────────┌────────────────┌────────┌──────────┌─────────────────
│    │    │ UploadDate    │ DateTimeOffset │        │    x     │                │
├────┌────┌───────────────┌────────────────┌────────┌──────────┌─────────────────
│    │    │ Image         │ File           │        │    x     │                │
└────┮────┮───────────────┮────────────────┮────────┮──────────┮────────────────┘

ì°žê³ : lino entity new 명령은 닀륞 시나늬였에서 독늜 entities륌 만듀Ʞ 위핎 졎재합니닀. entity가 êž°ì¡Ž aggregate 펞집의 음부가 아닐 때는 닀음을 사용합니닀: 

lino entity new --service <ServiceName> --module <ModuleName> --name <EntityName>

4. 닀륞 서비슀륌 위한 엔터티 생성

서비슀 쀑 Sales, 우늬는 엔터티륌 만듭니닀 ProductSnapshot, 읎는 통합 읎벀튞에 의핎 제공됩니닀. 엔터티의 원래 ID로 Product 서비슀에서 나옎 Catalog, 여Ʞ서는 자동 슝분될 수 없습니닀. 

lino entity new --service Sales --name ProductSnapshot
┌────┬────┬───────────────┬─────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type    │ Length │ Required │ Auto-increment │
├────┌────┌───────────────┌─────────┌────────┌──────────┌─────────────────
│ x  │    │ Id            │ Guid    │        │    x     │                │
├────┌────┌───────────────┌─────────┌────────┌──────────┌─────────────────
│    │    │ Name          │ string  │  100   │    x     │                │
├────┌────┌───────────────┌─────────┌────────┌──────────┌─────────────────
│    │    │ Price         │ decimal │        │    x     │                │
└────┮────┮───────────────┮─────────┮────────┮──────────┮────────────────┘

ì°žê³ : Sales 서비슀의 ProductSnapshot에는 핵심 fields만 복제했습니닀. Customer, Order, StockItem 같은 볎조 entities는 묞서륌 닚순하게 유지하Ʞ 위핎 여Ʞ서 자섞히 닀룚지 않습니닀. ProductSnapshot은 shadow entity로 동작합니닀. 슉, 소유자가 닀륞 서비슀에 있는 데읎터의 로컬, 최소, 제얎된 복사볞입니닀. 읎륌 통핎 Sales는 Catalog의 entity나 database에 직접 의졎하지 않고 필요한 제품 데읎터륌 조회할 수 있습니닀.

읎런 유형의 구조는 lino shadow-entity new의 alias읞 lino shadow new 명령윌로도 만듀 수 있습니닀. 읎 흐늄에서 Lino는 닀륞 service 또는 module의 entity 구조륌 복사하고, 소비하는 context에 의믞 있는 properties만 선택할 수 있게 합니닀. 

lino shadow new --service <ServiceName> --module <ModuleName> --name <ShadowEntityName>

예제에서 원볞 entity는 Catalog.Merchandising.Product읎고 대상은 Sales 서비슀읎며, 판맀에 필요한 fields만 유지합니닀.

읎벀튞 및 핎당 핞듀러 만듀Ʞ

요앜하자멎, 읎전 죌제에서는 몚듈식 서비슀륌 만듀었습니닀. Catalog.Merchandising 엔터티 Product, Category 귞늬고 ProductImage, 귌묎 쀑 Sales 우늬는 엔터티륌 만듭니닀 ProductSnapshot.

읎제 도메읞 읎벀튞와 통합 읎벀튞륌 만듀얎 볎겠습니닀. 목표는 서비슀에서 제품을 생성하거나 업데읎튞할 때 Catalog, 읎러한 변겜 사항은 닀음곌 같은 소비자 서비슀에 복제됩니닀. Sales 귞늬고 Stock.

1. 도메읞 읎벀튞 생성

첫 번짞 닚계는 도메읞 읎벀튞륌 만드는 것입니닀. ProductCreated 귞늬고 ProductUpdated 닀음 명령윌로: 

lino event new

생성하는 동안 읎벀튞륌 핞듀러와 연결하고 동시에 통합 읎벀튞의 발생을 구성할 수 있습니닀. 읎는 필요한 몚든 흐늄의 생성을 쀑앙 집쀑화합니닀. 

┌──────────────────────────────────────────────────────┬────────────────────────────────┐
│ Question                                             │ Answer                         │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a service:                                    │ Catalog                        │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a module:                                     │ Merchandising                  │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a entity:                                     │ Product                        │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select the event type:                               │ Domain Event                   │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Enter the name of the event:                         │ ProductCreated                 │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Do you want to create an associated event handler?   │ Yes                            │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Trigger a integration event?                         │ Yes                            │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Choose the integration event to be triggered:        │ (Create new integration event) │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Enter the name of the event:                         │ ProductCreated                 │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Which model will be used for this integration event? │ Creation model                 │
└──────────────────────────────────────────────────────┮────────────────────────────────┘

같은 방법윌로 읎벀튞륌 생성합니닀. ProductUpdated: 

┌──────────────────────────────────────────────────────┬────────────────────────────────┐
│ Question                                             │ Answer                         │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a service:                                    │ Catalog                        │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a module:                                     │ Merchandising                  │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select a entity:                                     │ Product                        │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Select the event type:                               │ Domain Event                   │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Enter the name of the event:                         │ ProductUpdated                 │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Do you want to create an associated event handler?   │ Yes                            │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Trigger a integration event?                         │ Yes                            │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Choose the integration event to be triggered:        │ (Create new integration event) │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Enter the name of the event:                         │ ProductUpdated                 │
├──────────────────────────────────────────────────────┌─────────────────────────────────
│ Which model will be used for this integration event? │ Update model                   │
└──────────────────────────────────────────────────────┮────────────────────────────────┘

읎륌 통핎 닀음을 얻을 수 있습니닀.

2. 통합 읎벀튞 핞듀러 생성

닀음 닚계는 통합 읎벀튞륌 사용할 서비슀륌 정의하는 것입니닀. 읎륌 위핎 닀음을 사용합니닀. 

lino event-handler new

생성 흐늄에는 닀음읎 포핚됩니닀.

예륌 듀얎 서비슀에서 Sales 우늬는 핞듀러륌 만듀었습니닀. ProductCreated 귞늬고 ProductUpdated 에 의핎 튞늬거된 읎벀튞륌 소비합니닀. Catalog.Merchandising.Product: 

┌────────────────────────────────────────────┬───────────────────┐
│ Question                                   │ Answer            │
├────────────────────────────────────────────┌────────────────────
│ Select a service:                          │ Sales             │
├────────────────────────────────────────────┌────────────────────
│ Select a entity:                           │ ProductSnapshot   │
├────────────────────────────────────────────┌────────────────────
│ Select the event type:                     │ Integration Event │
├────────────────────────────────────────────┌────────────────────
│ Select the event's service to be consumed: │ Catalog           │
├────────────────────────────────────────────┌────────────────────
│ Select the event's module to be consumed:  │ Merchandising     │
├────────────────────────────────────────────┌────────────────────
│ Select the event's entity to be consumed:  │ Product           │
├────────────────────────────────────────────┌────────────────────
│ Choose the event to be consumed:           │ ProductCreated    │
├────────────────────────────────────────────┌────────────────────
│ Enter the name of the event handler:       │ ProductCreated    │
└────────────────────────────────────────────┮───────────────────┘

┌────────────────────────────────────────────┬───────────────────┐
│ Question                                   │ Answer            │
├────────────────────────────────────────────┌────────────────────
│ Select a service:                          │ Sales             │
├────────────────────────────────────────────┌────────────────────
│ Select a entity:                           │ ProductSnapshot   │
├────────────────────────────────────────────┌────────────────────
│ Select the event type:                     │ Integration Event │
├────────────────────────────────────────────┌────────────────────
│ Select the event's service to be consumed: │ Catalog           │
├────────────────────────────────────────────┌────────────────────
│ Select the event's module to be consumed:  │ Merchandising     │
├────────────────────────────────────────────┌────────────────────
│ Select the event's entity to be consumed:  │ Product           │
├────────────────────────────────────────────┌────────────────────
│ Choose the event to be consumed:           │ ProductUpdated    │
├────────────────────────────────────────────┌────────────────────
│ Enter the name of the event handler:       │ ProductUpdated    │
└────────────────────────────────────────────┮───────────────────┘

읎륌 통핎 서비슀에는 두 개의 통합 읎벀튞 핞듀러가 있습니닀. Sales, 통합 읎벀튞에서 필요한 필드만 소비합니닀. Catalog.Merchandising. 읎렇게 하멎 복제된 테읎랔읎 필수 데읎터만 유지하여 슀토늬지와 성능을 최적화할 수 있습니닀. 아킀텍처 잡멎에서 예상되는 흐늄은 닀음곌 같습니닀. 명령 처늬Ʞ가 집계륌 변겜하고, 도메읞 읎벀튞가 발생하고, 처늬Ʞ가 통합 읎벀튞륌 쀀비하고, Outbox가 메시지륌 저장하고, Background Job읎 묞제륌 처늬하고, 메시징 엔진읎 소비자에게 메시지륌 전달합니닀. 읎렇게 하멎 서비슀 간의 동Ʞ 결합을 방지하고 핎당 읎벀튞가 게시되지 않고 데읎터베읎슀가 변겜될 위험읎 쀄얎듭니닀.

웹 페읎지, API, 명령 및 쿌늬 생성

의 가장 큰 장점 쀑 하나는 Lino CLI 웹 페읎지, API, 명령 및 쿌늬륌 자동화된 방식윌로 통합 생성하여 전첎 개발 흐늄을 닚순화하는 것입니닀. 도메읞 몚덞읎 충분히 안정적읎멎 읎 명령은 화멎에서 지속성까지의 전첎 겜로륌 생성하여 읎전 닚계에서 수행된 몚덞링 작업을 최종 사용자에게 표시합니닀. 시작하렀멎 닀음 명령을 싀행하멎 됩니닀. 

lino page new

읎 곌정에서 귀하는 닀음을 수행하게 됩니닀.

읎 명령을 사용하멎 읞터페읎슀 계잵, API 및 비슈니슀 로직을 수동윌로 작성하지 않고도 Ʞ능적읞 애플늬쌀읎션을 얻을 수 있윌며 서비슀 간의 표쀀곌 음ꎀ성을 유지합니닀. 귞렇더띌도 속성 메타데읎터만윌로는 몚든 규칙을 추론할 수 없윌므로 생성 후 비슈니슀 규칙곌 유횚성 검사륌 검토하섞요.

읎 프로젝튞에서는 닀음 엔터티에 대한 통합 페읎지륌 생성할 수 있습니닀.

페읎지, API 및 명령/쿌늬륌 생성한 후 애플늬쌀읎션은 프런튞엔드와 백엔드 간에 완벜하게 상혞 작용할 쀀비가 되며 검슝, 겜로 및 지속성은 읎믞 자동윌로 구성됩니닀. Lino CLI. 달늬닀 dotnet build 깚진 ì°žì¡°, 음ꎀ되지 않은 계앜 또는 최귌 몚덞 변겜의 영향을 조Ʞ에 식별합니닀.

마읎귞레읎션 생성 및 적용

엔터티, Value Object, 엎거형, ꎀ계, 읞슝, 테넌튾 지원 또는 Background Job 지속성을 생성하거나 변겜한 후 마읎귞레읎션을 생성하여 데읎터베읎슀와 윔드 정렬을 유지합니닀. 마읎귞레읎션은 몚덞 변겜 사항을 명시적읎고 버전 지정 가능하며 검토 가능한 아티팩튞로 변환합니닀.

귞만큌 Lino CLI Entity Framework륌 사용하여 읎 프로섞슀륌 조정하고, 올바륞 서비슀/몚듈을 선택하고, 현재 버전의 서비슀륌 사용하고, 생성된 슀크늜튞륌 구성하여 추적성을 용읎하게 합니닀.

1닚계: 마읎귞레읎션 만듀Ʞ

새 마읎귞레읎션을 만듀렀멎 닀음을 싀행하섞요. 

lino database migrations add

읎 명령은 닀음곌 같은 별칭도 허용할 수 있습니닀. lino database migrations new 귞늬고 lino database migrations create, 귞러나 묞서에서 선혞되는 방법은 닀음곌 같습니닀. add.

싀행 쀑에 닀음 사항을 알렀알 합니닀. 

┌───────────────────────────────────────────┬───────────────────┐
│ Question                                  │ Answer            │
├───────────────────────────────────────────┌────────────────────
│ Select a service:                         │ Catalog           │
├───────────────────────────────────────────┌────────────────────
│ Select a module:                          │ Merchandising     │
├───────────────────────────────────────────┌────────────────────
│ Current version of the service:           │ 0.1.0             │
├───────────────────────────────────────────┌────────────────────
│ Provide a description for this migration: │ Initial migration │
└───────────────────────────────────────────┮───────────────────┘

서비슀와 몚듈을 읎믞 알고 있윌멎 닀음 데읎터륌 직접 입력할 수 있습니닀. 

lino database migrations add --service <ServiceName> --module <ModuleName>

2닚계: 생성되는 ë‚Žìš©

생성을 확읞할 때 Lino는 선택한 서비슀 또는 몚듈 지속성 프로젝튞에 대한 올바륞 Entity Framework 명령을 쀀비합니닀. 몚듈식 서비슀에서는 마읎귞레읎션읎 핎당 몚듈에서 격늬된 상태로 유지되얎 서로 닀륞 컚텍슀튞의 변겜 사항읎 혌합되는 것을 방지합니닀.

3닚계: 마읎귞레읎션 나엎 및 적용

데읎터베읎슀에 변겜 사항을 적용하Ʞ 전에 알렀진 마읎귞레읎션을 나엎하고 예상되는 마읎귞레읎션읎 있는지 확읞하섞요. 

lino database migrations list --service <ServiceName> --module <ModuleName>

구성된 환겜에 마읎귞레읎션을 적용하렀멎 닀음 안낎륌 따륎섞요. 

lino database migrations apply --service <ServiceName> --module <ModuleName>

로컬 개발에서 읎 흐늄은 몚덞 검슝 속도륌 높입니닀. 공유 또는 프로덕션 환겜에서는 팀읎 정의한 배포 프로섞슀륌 통핎 마읎귞레읎션을 적용하고 필요한 겜우 슀크늜튞 검토, 승읞 및 백업을 수행합니닀.

4닚계: 통제된 환겜에서 되돌늬Ʞ 또는 제거

사용 revert 통제된 환겜에 적용된 마읎귞레읎션을 반환핎알 하는 겜우 마읎귞레읎션 낎용에 따띌 핎당 작업읎 파ꎎ적읞 명령을 싀행할 수 있닀는 점을 읎핎하섞요. 

lino database migrations revert --service <ServiceName> --module <ModuleName>

사용 remove 음반적윌로 변겜 사항을 컀밋하거나 게시하Ʞ 전에 컀밋되지 않은 마지막 마읎귞레읎션을 삭제합니닀. 

lino database migrations remove --service <ServiceName> --module <ModuleName>

몚범 사례

읎 흐늄을 따륎멎 데읎터베읎슀는 Lino에 정의된 도메읞 몚덞곌 음ꎀ성을 유지하며 각 슀킀마 변겜 사항은 묞서화되고 추적 가능하며 배포 전에 검토할 수 있습니닀.

5닚계: 애플늬쌀읎션을 로컬에서 검슝

project, Web App, services, modules, entities, migrations, APIs, Commands, Queries가 쀀비되멎 Docker images륌 생성하Ʞ 전에 애플늬쌀읎션을 검슝합니닀. 뚌저 solution을 빌드하여 생성된 몚든 projects, contracts, clients가 계속 음ꎀ적읞지 확읞합니닀: 

dotnet build

귞런 닀음 Aspire AppHost륌 통핎 애플늬쌀읎션을 싀행합니닀: 

dotnet run --project src/Aspire/AppHost/<ProjectName>.AppHost.csproj

Aspire dashboard륌 사용하여 APIs, Web App, database, cache, messaging, Background Jobs가 올바륎게 시작되었는지 확읞합니닀. 읎후 Backoffice에서 죌요 flows륌 테슀튞합니닀: 생성된 pages, Blazor에서 Api.Client projects로의 혞출, 적용된 migrations, 활성화된 겜우 authentication, 귞늬고 시나늬였에 포핚된 events 또는 jobs입니닀.

애플늬쌀읎션읎 빌드되고 로컬에서 싀행되며 죌요 flows가 검슝되멎, project는 packaging 닚계로 읎동할 쀀비가 된 것입니닀.

Docker 읎믞지 생성 쀑

애플늬쌀읎션읎 빌드되고 AppHost륌 통핎 로컬에서 싀행되며 죌요 flows가 테슀튞되멎, services와 web applications의 Docker images륌 생성하여 나쀑에 container registry에 게시할 수 있습니닀. 선택한 항목을 images로 팚킀징할 쀀비가 되었을 때 lino build륌 사용합니닀.

귞만큌 Lino CLI 닀음 명령을 사용하여 읎 프로섞슀륌 닚순화합니닀. 

lino build

싀행하멎 프로젝튞에서 사용할 수 있는 몚든 서비슀 및 웹 애플늬쌀읎션 목록곌 현재 버전읎 표시됩니닀. 

Select the services or web applications you want to include in the build:

> [ ] Services
    [ ] Catalog |0.1.0|
    [ ] Sales |0.1.0|
    [ ] Security |0.1.0|
    [ ] Stock |0.1.0|
  [ ] Web applications
    [ ] Backoffice |0.1.0|

하나 읎상의 서비슀와 웹 애플늬쌀읎션을 선택하여 읎믞지륌 동시에 생성할 수 있습니닀. 원하는 항목을 표시하멎 됩니닀.

귞런 닀음 생성된 읎믞지의 버전을 업데읎튞할 방법을 선택하띌는 메시지가 표시됩니닀. 사용 가능한 옵션은 닀음곌 같습니닀.

서비슀륌 선택하고 버전 슝분을 정의한 후 Lino CLI 닀음을 수행합니닀:

프로섞슀가 끝나멎 몚든 웹 서비슀와 애플늬쌀읎션읎 선택되었음을 고렀하여 생성된 읎믞지는 닀음곌 같은 구조륌 갖습니닀.

음반적윌로 ê°„ë‹ší•œ 서비슀는 닀음곌 같은 저장소륌 생성하는 겜향읎 있습니닀. project-name/services/service-name-api:1.2.3, 몚듈형 서비슀는 혞슀튞륌 닀음곌 같읎 사용합니닀. project-name/services/service-name-host:1.2.3및 Blazor 애플늬쌀읎션은 닀음곌 같은 겜로륌 사용합니닀. project-name/webapps/webapp-name:1.2.3.

ꎀ찰: 읎 프로섞슀는 윔드와 Docker 읎믞지 버전 간의 음ꎀ성을 볎장하여 여러 환겜의 배포 및 유지 ꎀ늬륌 쎉진할 뿐만 아니띌 각 서비슀륌 독늜적읞 컚테읎너에 격늬할 수 있습니닀. 로컬 읎믞지가 생성된 후 배포 플랫폌에서 사용하는 레지슀튞늬(예: Docker Hub, GitHub Container Registry, AWS ECR, Azure Container Registry 또는 닀륞 OCI 혾환 레지슀튞늬)에 게시합니닀. 읎믞지 낎에 비밀, 프로덕션 연결 묞자엎 또는 자격 슝명을 포핚하지 마섞요.

애플늬쌀읎션에서 버전 생성

Lino는 각 서비슀의 욎영 버전을 유지 ꎀ늬합니닀. src/Services/<ServiceName>/version.txt 귞늬고 각 웹 애플늬쌀읎션 src/WebApps/<WebAppName>/version.txt. 읎륌 통핎 배포 가능한 각 항목에 대핮 독늜적읞 늎늬슀륌 계획할 수 있습니닀.

버전을 변겜하Ʞ 전에 현재 상태륌 검사하섞요. 

lino version list

사용 lino version show 특정 서비슀나 웹 애플늬쌀읎션을 ì°žì¡°í•Žì•Œ 할 때.

웹 서비슀 또는 애플늬쌀읎션의 새 버전을 늘늬는 것은 간닚하고 쀑앙 집쀑화된 프로섞슀입니닀. Lino CLI. 닀음 명령을 싀행하섞요. 

lino version bump

Docker 읎믞지륌 생성하는 것곌 마찬가지로 읎 명령을 싀행하멎 프로젝튞에 있는 몚든 서비슀 및 웹 애플늬쌀읎션의 전첎 목록읎 표시됩니닀. 선택한 항목만 버전읎 올띌가고 나뚞지 항목은 변겜되지 않습니닀. 

Select the services or web applications that will have version changes:

> [ ] Services
    [ ] Catalog |0.1.0|
    [ ] Sales |0.1.0|
    [ ] Security |0.1.0|
    [ ] Stock |0.1.0|
  [ ] Web applications
    [ ] Backoffice |0.1.0|

원하는 항목을 선택한 후 버전 슝분 유형을 선택하띌는 메시지가 표시됩니닀. 사용 가능한 옵션은 닀음곌 같습니닀.

웹 서비슀 및 애플늬쌀읎션의 버전읎 닀음에 직접적읞 영향을 믞친닀는 점을 강조하는 것읎 쀑요합니닀.

범프륌 적용하Ʞ 전에 늎늬슀의 음부읞 윔드 변겜 사항, 마읎귞레읎션, 통합 읎벀튞, API 계앜 및 프런튞엔드 변겜 사항을 검토하섞요. 한 가지 버전 반점 혾환 가능한 수정사항을 나타낎알 합니닀. 믞성년자 혾환 가능한 추가 항목을 나타낎알 하며, 죌요한 소비자가 적응핎알 하는 변겜을 위핎 예앜되얎알 합니닀.

읎것윌로 우늬는 닀음을 사용하여 웹 프로젝튞륌 구축하는 데 필요한 몚든 필수 명령에 대한 닚계별 가읎드륌 마묎늬합니닀. Lino CLI, 섀치부터 서비슀, 엔터티, 읎벀튞 및 페읎지 생성부터 Docker 읎믞지 생성 및 버전 ꎀ늬까지. 도메읞 몚덞링, 사용 사례 및 화멎 생성, 빌드 및 테슀튞륌 통한 검슝, 마읎귞레읎션 생성, 버전 태귞가 있는 읎믞지 게시, 명시적읞 SemVer 값을 사용하여 각 서비슀 또는 웹 애플늬쌀읎션 늎늬슀 등 전첎 흐늄을 추적할 수 있습니닀.

저희 채널을 팔로우하는 것을 잊지 마섞요. 유튜람 ê°„ë‹ší•œ 조작부터 고꞉ Ʞ능까지 도구 사용에 대한 자섞한 튜토늬얌, 싀제 데몚 및 팁을 따륎십시였.

처리되지 않은 오류가 발생했습니다. 새로 고침 🗙