Ignore: 🔧 Divide Domain Modules For Multiple Infrastructure

[psychology50]

작업 이유

Inital Architecture

We originally chose an architecture resembling the image below:

• Data Sources: Could be MySQL, Redis, or others depending on the entity.
• Structure: We divided packages based on data sources:

C:.
├───common
│   └───redis
│       └───session
└───domains
    └───user

Problems Encountered

1. Domain Logic Placement: Cross-entity business logic was forced into the lowest-level modules, leading to tightly coupled, entity-specific services.
2. Domain Purity: Domains should be agnostic to the data source, focusing solely on business rules.
3. Test Complexity: Both Redis and JPA setups were required for DAO testing.

Suggested Advanced Architecture

A more scalable approach includes the following improvements:

• Single Responsibility: Each domain module manages only one infrastructure type.
• Centralized Domain Logic: All domain business logic resides in the domain service module, promoting:
  • Low Coupling: Clear separation of concerns.
  • High Cohesion: Logical grouping of related functionality.

This architecture ensures scalability and simplifies testing while maintaining clean boundaries between domains and infrastructures.

작업 사항

1. Module Restructuring

   • Created domain-service module for core business logic
   • Separated domain-rds and domain-redis modules

2. Service Layer Changes

   • Implemented storage-specific logic in respective modules
   • Updated naming convention: *RdbService and *RedisService

3. Testing Improvements

   • Converted integration tests to unit tests
   • Removed unnecessary test case
   • Added proper mocking strategies

Current Limitations and Migration Strategy

1. Pragmatic Approach to Domain Logic

   • Ideal State: Lower-level modules should only depend on domain-service
   • Current Reality: Domain logic remains distributed across modules
   • Reason: Avoiding large-scale refactoring of existing business logic

2. Gradual Migration Strategy
   Phase 1 (Current)

   • Establish new module structure
   • Keep existing domain logic in place
   • Minimize immediate changes to running systems

   Phase 2 (Future)

   • Gradually move domain logic to domain-service
   • Update dependencies one service at a time
   • Maintain backward compatibility

3. Trade-offs Made

   • Accepting temporary architectural compromise
   • Prioritizing system stability over immediate perfect structure
   • Allowing for smoother transition period

4. Guidelines for New Features

• Core domain logic should be placed in domain-service
• However, non-core logic (e.g., simple CRUD, caching) remains in lower-level services
• Examples:

  Core Domain Logic (domain-service):
  - Complex business rules involving multiple entities
  - Critical validation rules
  - Coordinating multiple services
  
  Non-core Logic (infrastructure services):
  - Simple CRUD operations
  - Basic data validation
  - Cache management
  - Infrastructure-specific operations

• Existing logic can be migrated opportunistically
• Document clear patterns for both approaches

리뷰어가 중점적으로 확인해야 하는 부분

1. Dependency Direction

   • domain-service depends on infrastructure modules (domain-rds, domain-redis)
   • This intentional choice enables:
     • Direct Entity usage in domain logic
     • Gathering validation logic
     • Practical development workflow

   Trade-offs Considered:

   • Pros:
     • Avoid duplicate validation/creation rules
     • Maintain single source of truth for Entity structure
     • Reduce complexity in data transformation
   • Cons:
     • Domain logic has knowledge of persistence details
     • Tighter coupling with specific implementations
     • Less flexibility in storage implementations

2. Service Naming and Structure

   • Verify consistent naming: *RdbService and *RedisService for infrastructure
   • Check proper integration in domain-service
   • Check if any business logic leaked into infrastructure layers

3. Test Coverage

   • Verify if all important scenarios are covered
   • Check if mocking strategies are appropriate
   • Ensure test readability and maintainability

발견한 이슈

1. Some services still have tight coupling with Entity structures

   • Consider introducing DTOs for complete separation
   • Currently accepted for practical reasons

2. Configuration Management

   • Need to standardize configuration across modules
   • Consider creating shared configuration module

3. Transaction Management

   • Current implementation handles transactions per-repository
   • May need distributed transaction solution in future

4. Migration Strategy

   • Gradual migration approach for existing features
   • Need to document migration guidelines