ranggarifqi/mcp-weather

MCP Weather Server

A Model Context Protocol (MCP) server for weather information, built with Domain-Driven Design (DDD) principles.

Project Structure (DDD)

mcp-weather/
├── src/
│   ├── McpWeather.Domain/              # Domain Layer (Core Business Logic)
│   │   ├── Entities/                   # Domain entities with identity
│   │   ├── ValueObjects/               # Immutable value objects
│   │   ├── Repositories/               # Repository interfaces
│   │   ├── Services/                   # Domain services
│   │   └── Events/                     # Domain events
│   │
│   ├── McpWeather.Application/         # Application Layer
│   │   ├── UseCases/                   # Application use cases
│   │   ├── DTOs/                       # Data transfer objects
│   │   ├── Interfaces/                 # Application service interfaces
│   │   └── Services/                   # Application services
│   │
│   ├── McpWeather.Infrastructure/      # Infrastructure Layer
│   │   ├── ExternalServices/           # External API integrations (weather APIs)
│   │   ├── Persistence/                # Data persistence implementations
│   │   └── Configuration/              # Infrastructure configuration
│   │
│   └── McpWeather.Server/              # Presentation Layer
│       └── Program.cs                  # MCP server entry point
│
├── tests/
│   ├── McpWeather.Domain.Tests/        # Domain layer tests
│   ├── McpWeather.Application.Tests/   # Application layer tests
│   ├── McpWeather.Infrastructure.Tests/ # Infrastructure layer tests
│   └── McpWeather.Server.Tests/        # Server layer tests
│
└── docs/                               # Documentation

DDD Layers

Domain Layer (McpWeather.Domain)

The heart of the application containing pure business logic with no external dependencies.

• Entities: Core business objects with unique identity (e.g., WeatherForecast, Location)
• Value Objects: Immutable objects without identity (e.g., Temperature, Coordinates, WindSpeed)
• Repository Interfaces: Contracts for data access abstraction
• Domain Services: Business logic that doesn't naturally fit within entities
• Domain Events: Events that occur within the domain

Application Layer (McpWeather.Application)

Orchestrates domain objects to fulfill application-specific use cases.

• Use Cases: Application-specific business rules and workflows
• DTOs: Data structures for transferring data between layers
• Interfaces: Contracts for infrastructure services (e.g., IWeatherApiClient)
• Application Services: Coordinate application logic and use cases

Infrastructure Layer (McpWeather.Infrastructure)

Handles external concerns and provides implementations for interfaces defined in inner layers.

• External Services: Weather API clients (OpenWeatherMap, WeatherAPI, etc.)
• Persistence: Database implementations, caching, repository implementations
• Configuration: Infrastructure setup, dependency injection configuration

Server Layer (McpWeather.Server)

Entry point for the MCP server, handles communication protocol and dependency injection.

• MCP server implementation
• Dependency injection container setup
• Request/response handling

Dependency Flow

Server → Infrastructure → Application → Domain
        ↑                 ↑              ↑
        └─────────────────┴──────────────┘
          (Dependencies point inward)

• Domain has no dependencies
• Application depends only on Domain
• Infrastructure depends on Application and Domain
• Server depends on all layers but primarily Infrastructure

Getting Started

Prerequisites

• .NET 8.0 SDK or later

Building

dotnet build

Running

dotnet run --project src/McpWeather.Server/McpWeather.Server.csproj

Testing

Run all tests:

dotnet test

Run specific layer tests:

dotnet test tests/McpWeather.Domain.Tests
dotnet test tests/McpWeather.Application.Tests
dotnet test tests/McpWeather.Infrastructure.Tests
dotnet test tests/McpWeather.Server.Tests

Development Guidelines

DDD Principles

1. Ubiquitous Language: Use domain terminology consistently across all layers
2. Bounded Context: Keep weather-related concepts within clear boundaries
3. Entity vs Value Object:
   • Use Entities for objects that need identity and lifecycle tracking
   • Use Value Objects for descriptive characteristics
4. Aggregate Roots: Define clear aggregate boundaries and access patterns
5. Repository Pattern: Access aggregates only through repositories
6. Domain Events: Communicate changes within the domain

Layer Responsibilities

• Domain: Should be framework-agnostic and contain pure C# code
• Application: Should not contain business rules, only orchestration
• Infrastructure: Should not contain business logic
• Server: Should be thin, focusing on protocol handling

License

TBD