Границы доменов

Previous Next

Domain Boundaries определяют четкие границы между доменами в системе, обеспечивая высокую связность внутри домена (high cohesion) и слабую связность между доменами (loose coupling). Следуем принципам Domain-Driven Design (DDD).

Bounded Contexts

graph TB subgraph "Identity Context" User[User Aggregate] Identifier[Identifier Aggregate] Verification[Verification Aggregate] end subgraph "Credential Context" Password[Password Aggregate] end subgraph "Auth Context" Session[Session Aggregate] Token[Token Value Object] end subgraph "Account Context" Account[Account Aggregate] Team[Team Aggregate] Subscription[Subscription Aggregate] end subgraph "Notification Context" NotificationTemplate[Template Aggregate] Delivery[Delivery Aggregate] end User -.->|user_id| Password User -.->|user_id| Session User -.->|user_id| Account Identifier -.->|user_id| User Verification -.->|user_id| User Session -.->|user_id| User Session -->|contains| Token Account -.->|user_id| User Team -.->|account_id| Account Subscription -.->|account_id| Account style User fill:#4A90E2 style Password fill:#51B749 style Session fill:#FFA500 style Account fill:#9B59B6

Принципы определения границ

1. Bounded Context = Микросервис

Каждый bounded context реализуется как отдельный микросервис:

1
2
3
4
5
Identity Context      → Identity Service
Credential Context    → Credential Service
Auth Context          → Auth Service
Account Context       → Account Service
Notification Context  → Herald Service

2. Database per Service

Каждый сервис владеет своей базой данных:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
-- identity_production (PostgreSQL)
CREATE DATABASE identity_production;
-- Tables: users, identifiers, verification_challenges

-- credential_production (PostgreSQL)
CREATE DATABASE credential_production;
-- Tables: password_credentials

-- account_production (PostgreSQL)
CREATE DATABASE account_production;
-- Tables: accounts, teams, subscriptions

Запрещено: - ❌ Direct database access между сервисами - ❌ Shared database между сервисами - ❌ Foreign keys между базами разных сервисов

Разрешено: - ✅ gRPC/REST API calls между сервисами - ✅ Event-driven communication через Kafka - ✅ Денормализация данных (eventual consistency)

3. Aggregate Design

Каждый aggregate — это transactional boundary:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# Identity Service
class User:
    """User aggregate root"""
    id: UUID
    username: str
    status: UserStatus
    # ... other fields

    # Invariants protected within aggregate
    def disable(self) -> "User":
        if self.status == UserStatus.DELETED:
            raise UserAlreadyDeletedError()
        return User(..., status=UserStatus.DISABLED, disabled_at=utc_now())

class Identifier:
    """Identifier aggregate (separate from User)"""
    id: UUID
    user_id: UUID  # Reference to User aggregate
    type: IdentifierType
    value: str
    verified_at: datetime | None

Правила: - Один aggregate = одна транзакция - Связи между aggregates только через ID (no object references) - Invariants enforced только внутри aggregate

Domain Boundaries — детализация

Identity Domain

Ответственность: Управление пользователями и их идентификаторами (email, phone).

Aggregates: - User — корневой aggregate, статус пользователя - Identifier — email/phone, привязанные к пользователю - VerificationChallenge — OTP коды для верификации

Owned Data: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# users table
class User:
    id: UUID
    username: str
    status: UserStatus  # ACTIVE, DISABLED, DELETED
    created_at: datetime
    updated_at: datetime
    disabled_at: datetime | None
    deleted_at: datetime | None

# identifiers table
class Identifier:
    id: UUID
    user_id: UUID
    type: IdentifierType  # EMAIL, PHONE
    value: str
    verified_at: datetime | None
    created_at: datetime

# verification_challenges table (Redis)
class VerificationChallenge:
    challenge_id: str
    user_id: UUID
    identifier_value: str
    identifier_type: str
    code_hash: str
    attempts: int
    status: ChallengeStatus
    expires_at: datetime

Public API (gRPC): 

1
2
3
4
5
6
7
8
9
service IdentityService {
  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
  rpc GetUserByUsername(GetUserByUsernameRequest) returns (GetUserResponse);
  rpc DisableUser(DisableUserRequest) returns (DisableUserResponse);
  rpc AttachIdentifier(AttachIdentifierRequest) returns (AttachIdentifierResponse);
  rpc StartVerification(StartVerificationRequest) returns (StartVerificationResponse);
  rpc ConfirmVerification(ConfirmVerificationRequest) returns (ConfirmVerificationResponse);
}

Published Events: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# identity.user.events
EventType.USER_CREATED
EventType.USER_DISABLED
EventType.USER_ENABLED
EventType.USER_DELETED

# identity.identifier.events
EventType.IDENTIFIER_ADDED
EventType.IDENTIFIER_VERIFIED
EventType.IDENTIFIER_REMOVED

Credential Domain

Ответственность: Безопасное хранение и верификация паролей.

Aggregates: - PasswordCredential — единственный aggregate

Owned Data: 

1
2
3
4
5
6
7
# password_credentials table
class PasswordCredential:
    user_id: UUID  # PK, reference to Identity.User
    password_hash: str  # Argon2id hash
    must_change: bool
    created_at: datetime
    updated_at: datetime

Public API (gRPC): 

1
2
3
4
5
service CredentialService {
  rpc SetPassword(SetPasswordRequest) returns (SetPasswordResponse);
  rpc VerifyPassword(VerifyPasswordRequest) returns (VerifyPasswordResponse);
  rpc ChangePassword(ChangePasswordRequest) returns (ChangePasswordResponse);
}

Published Events: 

1
2
3
4
# credential.password.events
EventType.PASSWORD_SET
EventType.PASSWORD_CHANGED
EventType.PASSWORD_VERIFIED  # For audit purposes

Security Principle: Credential Service НИКОГДА не возвращает пароли или хеши. Только true/false на верификацию.

Auth Domain

Ответственность: Управление сессиями и токенами.

Aggregates: - Session — корневой aggregate, сессия пользователя

Owned Data: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# sessions (Redis)
class Session:
    id: UUID
    user_id: UUID  # Reference to Identity.User
    refresh_token_hash: str
    created_at: datetime
    expires_at: datetime
    last_used_at: datetime
    user_agent: str | None
    ip_address: str | None

Public API (gRPC): 

1
2
3
4
5
service AuthService:
    rpc CreateSession(CreateSessionRequest) returns (CreateSessionResponse)
    rpc RefreshTokens(RefreshTokensRequest) returns (RefreshTokensResponse)
    rpc RevokeSession(RevokeSessionRequest) returns (RevokeSessionResponse)
    rpc ValidateSession(ValidateSessionRequest) returns (ValidateSessionResponse)

Published Events: 

1
2
3
4
# auth.session.events (planned)
EventType.SESSION_CREATED
EventType.SESSION_REFRESHED
EventType.SESSION_REVOKED

Account Domain

Ответственность: Управление организационными аккаунтами, командами, подписками.

Aggregates: - Account — корневой aggregate, организационный аккаунт - Team — команда внутри аккаунта - Subscription — подписка аккаунта

Owned Data: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# accounts table
class Account:
    id: UUID
    owner_user_id: UUID  # Reference to Identity.User
    name: str
    status: AccountStatus
    created_at: datetime

# teams table
class Team:
    id: UUID
    account_id: UUID  # FK to accounts
    name: str
    created_at: datetime

# subscriptions table
class Subscription:
    id: UUID
    account_id: UUID  # FK to accounts
    plan: SubscriptionPlan
    status: SubscriptionStatus
    started_at: datetime
    expires_at: datetime | None

Consumed Events: 

1
2
3
4
5
6
7
# Listens to identity.user.events
async def on_user_created(event: UserCreatedEvent):
    """Auto-create personal account for new user"""
    await create_account(
        owner_user_id=event.user_id,
        name=f"{event.username}'s Account"
    )

Notification Domain (Herald)

Ответственность: Отправка уведомлений (email, SMS, push).

Aggregates: - NotificationTemplate — шаблоны сообщений - Delivery — запись о доставке уведомления

Consumed Events: 

1
2
3
4
# Listens to multiple topics
identity.user.events       → Welcome email on user.created
identity.identifier.events → Send OTP on verification.started
credential.password.events → Password changed notification

External Integrations: - SendGrid (email) - Twilio (SMS) - Firebase Cloud Messaging (push)

Cross-Domain Communication Patterns

1. Synchronous (gRPC)

Используется для операций, требующих немедленного ответа:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# API Gateway вызывает Identity Service
async def register_user(username: str, password: str):
    # 1. Create user in Identity Service
    user = await identity_client.CreateUser(
        CreateUserRequest(username=username)
    )

    # 2. Set password in Credential Service
    await credential_client.SetPassword(
        SetPasswordRequest(user_id=user.id, password=password)
    )

    return user

2. Asynchronous (Kafka Events)

Используется для eventual consistency и loosely coupled integration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# Identity Service publishes event
async def create_user(username: str) -> User:
    async with uow.transaction() as tx:
        user = User(id=uuid4(), username=username, ...)
        await tx.users.create(user)

        # Publish event (via Transactional Outbox)
        await tx.outbox.create(OutboxEvent(
            topic="identity.user.events",
            event_type="user.created",
            payload={"user_id": str(user.id), ...}
        ))

    return user

# Account Service consumes event
@consumer.subscribe("identity.user.events")
async def on_user_created(event: UserCreatedEvent):
    """Auto-create account for new user"""
    await create_account(owner_user_id=event.user_id)

3. Saga Pattern (Distributed Transactions)

Для операций, требующих координации нескольких сервисов:

sequenceDiagram participant API participant Identity participant Credential participant Account participant Kafka API->>Identity: CreateUser(username) Identity->>Kafka: UserCreatedEvent Kafka->>Account: Consume UserCreatedEvent Account->>Account: CreateAccount alt Account creation success Account->>Kafka: AccountCreatedEvent else Account creation failed Account->>Kafka: AccountCreationFailedEvent Kafka->>Identity: Consume failure Identity->>Identity: Mark user for cleanup end

Shared Kernel (минимальный)

Общие концепции, используемые во всех сервисах:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Общие контракты / типы (libs/python/common/service-contracts, common/utils/utc-datetime)
class UUID(BaseModel): ...
class DateTime(BaseModel): ...

# Common patterns (libs/python/storage/patterns/unit-of-work-kit)
class AsyncUnitOfWork: ...
class AsyncUowTransaction: ...

# Common events (libs/python/storage/patterns/omni-box)
class OutboxEvent: ...
class EventType(StrEnum): ...

Принцип: Shared Kernel должен быть минимальным. Дублирование кода лучше, чем tight coupling.

Anti-patterns (избегаем)

❌ Distributed Monolith

1
2
3
4
5
6
# BAD: Прямой доступ к БД другого сервиса
async def get_user_with_password(user_id: UUID):
    # Identity Service обращается к credential_db напрямую
    user = await identity_db.query(User).get(user_id)
    password = await credential_db.query(Password).get(user_id)  # ❌
    return user, password

Правильно: 

1
2
3
4
5
# GOOD: Через API
async def get_user_with_credential_status(user_id: UUID):
    user = await identity_service.GetUser(user_id)
    has_password = await credential_service.HasPassword(user_id)
    return user, has_password

❌ Chatty Communication

1
2
3
4
5
6
7
8
# BAD: N+1 запросов
async def get_users_with_passwords(user_ids: list[UUID]):
    result = []
    for user_id in user_ids:  # N запросов!
        user = await identity_service.GetUser(user_id)
        has_pwd = await credential_service.HasPassword(user_id)
        result.append((user, has_pwd))
    return result

Правильно: 

1
2
3
4
5
# GOOD: Batch API
async def get_users_with_passwords(user_ids: list[UUID]):
    users = await identity_service.BatchGetUsers(user_ids)  # 1 request
    pwd_statuses = await credential_service.BatchHasPasswords(user_ids)  # 1 request
    return list(zip(users, pwd_statuses))

❌ Anemic Domain Model

1
2
3
4
5
6
7
8
9
# BAD: Domain logic в сервисе
class UserService:
    async def disable_user(self, user_id: UUID):
        user = await repo.get(user_id)
        if user.status == "deleted":  # ❌ Business logic в сервисе
            raise Error()
        user.status = "disabled"
        user.disabled_at = utc_now()
        await repo.update(user)

Правильно: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# GOOD: Domain logic в aggregate
class User:
    def disable(self) -> "User":
        """Domain method with invariants"""
        if self.status == UserStatus.DELETED:
            raise UserAlreadyDeletedError()
        return User(..., status=UserStatus.DISABLED, disabled_at=utc_now())

class DisableUserUseCase:
    async def execute(self, user_id: UUID) -> UserDTO:
        async with uow.transaction() as tx:
            user = await tx.users.get_by_id(user_id)
            disabled_user = user.disable()  # ✅ Domain logic
            await tx.users.update(disabled_user)
        return UserDTO.from_entity(disabled_user)

Связанные страницы

Архитектурные принципы Принципы проектирования API