Последний проект был многомодульным или одномодульным

Ответ: Архитектура проекта (многомодульность)

Прямой ответ

Последний проект был многомодульным. Это более современный и масштабируемый подход, позволяющий лучше разделить ответственность и управлять сложностью.

Структура многомодульного проекта

my-project/
├── pom.xml (parent POM)
├── core-module/
│   ├── pom.xml
│   ├── src/main/java
│   └── src/test/java
├── api-module/
│   ├── pom.xml
│   ├── src/main/java
│   └── src/test/java
├── service-module/
│   ├── pom.xml
│   ├── src/main/java
│   └── src/test/java
├── persistence-module/
│   ├── pom.xml
│   ├── src/main/java
│   └── src/test/java
└── application/
    ├── pom.xml
    └── src/main/java

Как это было организовано

Parent POM определял общие зависимости и версии:

<!-- pom.xml в корне проекта -->
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0.0</version>
    <packaging>pom</packaging>
    
    <properties>
        <spring.version>6.0.0</spring.version>
        <java.version>17</java.version>
    </properties>
    
    <modules>
        <module>core-module</module>
        <module>api-module</module>
        <module>service-module</module>
        <module>persistence-module</module>
        <module>application</module>
    </modules>
    
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-bom</artifactId>
                <version>${spring.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

Назначение каждого модуля

1. Core Module (ядро)

Отвечает за: домен-модели, бизнес-логику, исключения

Примеры классов:
- User.java (Entity)
- Order.java (Entity)
- OrderStatus.java (Enum)
- UserNotFoundException.java (Exception)
- OrderService interface (Business logic)

// core-module/src/main/java
public class User {
    private String id;
    private String name;
    private String email;
    
    public void changeEmail(String newEmail) {
        if (!isValidEmail(newEmail)) {
            throw new InvalidEmailException();
        }
        this.email = newEmail;
    }
}

2. Persistence Module (БД)

Отвечает за: Repository, Database queries, JPA/Hibernate

Примеры:
- UserRepository.java
- OrderRepository.java
- Database migration scripts
- Entity mappings

// persistence-module/src/main/java
public interface UserRepository extends JpaRepository<User, String> {
    Optional<User> findByEmail(String email);
    List<User> findAllByStatus(UserStatus status);
}

3. Service Module (сервисы)

Отвечает за: Business logic, Transactions, Orchestration

Примеры:
- UserService.java
- OrderService.java
- PaymentService.java

// service-module/src/main/java
@Service
public class UserService {
    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;
    
    @Transactional
    public User createUser(CreateUserRequest request) {
        User user = new User();
        user.setEmail(request.getEmail());
        user.setPassword(passwordEncoder.encode(request.getPassword()));
        return userRepository.save(user);
    }
}

4. API Module (REST endpoints)

Отвечает за: REST controllers, DTOs, Request/Response mapping

Примеры:
- UserController.java
- OrderController.java
- UserDTO.java
- CreateUserRequest.java

// api-module/src/main/java
@RestController
@RequestMapping("/api/v1/users")
public class UserController {
    private final UserService userService;
    
    @PostMapping
    public ResponseEntity<UserDTO> createUser(@RequestBody CreateUserRequest request) {
        User user = userService.createUser(request);
        return ResponseEntity.ok(UserDTO.fromEntity(user));
    }
    
    @GetMapping("/{id}")
    public ResponseEntity<UserDTO> getUser(@PathVariable String id) {
        User user = userService.getUser(id);
        return ResponseEntity.ok(UserDTO.fromEntity(user));
    }
}

5. Application Module (главное приложение)

Отвечает за: Spring Boot Application, Configuration, Dependency injection setup

Примеры:
- Application.java (Main class)
- ApplicationConfiguration.java
- SecurityConfiguration.java

// application/src/main/java
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Зависимости между модулями

Application
    ↓ зависит от
API Module + Service Module
    ↓ зависят от
Core Module + Persistence Module
    ↓ зависят от
Жди более нижних уровней

Важное правило: модули могут зависеть от более низких, но НЕ наоборот:

<!-- api-module/pom.xml -->
<dependencies>
    <!-- ✅ Правильно: зависит от core и service -->
    <dependency>
        <groupId>com.mycompany</groupId>
        <artifactId>core-module</artifactId>
    </dependency>
    <dependency>
        <groupId>com.mycompany</groupId>
        <artifactId>service-module</artifactId>
    </dependency>
</dependencies>

<!-- Но service-module НИКОГДА не зависит от api-module! -->

Преимущества многомодульной архитектуры

1. Разделение ответственности (SRP)

Каждый модуль отвечает за одно:
- core: домен и бизнес-логика
- service: оркестрация бизнес-процессов
- api: REST endpoint
- persistence: работа с БД

2. Повторное использование

// Модуль core может использоваться в разных приложениях
// - в REST API (api-module)
// - в batch приложении
// - в другом микросервисе

3. Масштабируемость

Можно легко добавлять новые модули:
- notification-module (отправка писем, SMS)
- payment-module (интеграция с платежками)
- reporting-module (аналитика и отчеты)

4. Параллельная разработка

Разные команды могут работать над разными модулями
без конфликтов в коде

5. Тестирование

// Модули можно тестировать отдельно
// core-module имеет свои unit тесты
// service-module имеет свои integration тесты
// api-module имеет свои controller тесты

6. Производительность сборки

Можно собирать отдельные модули
mvn clean install -pl api-module,service-module
// Не собираются модули, которые не изменились

Типичные проблемы и решения

Проблема 1: Циклические зависимости

❌ Плохо:
api-module → service-module → api-module

✅ Решение:
Промежуточный модуль:
api-module → service-module
api-module → core-module
service-module → core-module

Проблема 2: Общие зависимости

<!-- parent pom.xml -->
<dependencyManagement>
    <dependencies>
        <!-- Все версии в одном месте -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>6.0.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- Каждый модуль просто использует без версии -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <!-- версия наследуется от parent -->
</dependency>

Сравнение: Mono vs Multi-module

Когда выбирать многомодульность

✅ Выбирайте многомодульность когда:

• Проект большой и сложный (200+ классов)
• Несколько команд разработчиков
• Код нужно повторно использовать
• Долгосрочный проект

❌ Одномодульный достаточно для:

• MVP и стартапов
• Прототипов
• Маленьких приложений
• Проектов, которые развиваются вертикально в одну сторону

Резюме

Многомодульная архитектура позволяет:

• Разделить ответственность между модулями
• Реиспользовать компоненты
• Масштабировать проект
• Параллельно разрабатывать разными командами
• Быстрее собирать только нужные части

Это требует немного больше планирования в начале, но окупается намного быстрее по мере роста проекта.