Gymterview
senior

Как проектировать приложение, совместимое с DC и Cloud?

Создание dual-platform приложения — сложная задача, требующая архитектурного разделения платформенно-зависимого и бизнес-кода через общие интерфейсы и отдельные адаптеры для каждой платформы.

Архитектурный подход

Пример
┌──────────────────────────────────────────────┐
│              Shared Business Logic            │
│         (Java library / shared module)        │
│  ┌─────────────┐  ┌──────────┐  ┌──────────┐ │
│  │ Domain Model│  │ Business │  │  Utils   │ │
│  │  (POJOs)    │  │  Rules   │  │          │ │
│  └─────────────┘  └──────────┘  └──────────┘ │
└──────────┬──────────────────┬────────────────┘
           │                  │
    ┌──────┴──────┐    ┌──────┴──────┐
    │  DC Adapter │    │Cloud Adapter│
    │ P2 Plugin   │    │Forge / Conn.│
    │ Active Obj. │    │ Storage API │
    │ Jira Java   │    │ REST API v3 │
    │ Velocity UI │    │ UI Kit/React│
    └─────────────┘    └─────────────┘

Пример: абстракция над Jira API

Пример
// Общий интерфейс (shared module)
public interface JiraIssueAdapter {
    IssueDto getIssue(String key);
    String createIssue(CreateIssueRequest request);
    List<IssueDto> searchByJql(String jql, int maxResults);
}

public record IssueDto(
        String key, String summary, String status,
        String assignee, String projectKey,
        Map<String, Object> customFields
) {}

// DC реализация — Jira Java API напрямую
@Named
public class DcJiraIssueAdapter implements JiraIssueAdapter {
    @Inject
    public DcJiraIssueAdapter(@ComponentImport IssueManager issueManager,
                              @ComponentImport SearchService searchService) {
        // ...
    }
}

// Cloud реализация — REST API v3 через Forge
// (TypeScript, отдельный проект)

Стратегия миграции данных

Пример
DC (Active Objects)          Cloud (Forge Storage)
┌──────────────────┐         ┌──────────────────┐
│  AO Table        │  export │  Entity Storage  │
│  - ID            │ ──────→ │  - key           │
│  - PROJECT_KEY   │         │  - projectKey    │
│  - CONFIG        │  import │  - config        │
└──────────────────┘         └──────────────────┘

Частые ошибки

  • Попытка создать единый codebase для DC и Cloud — языки и рантайм разные (Java vs TypeScript)
  • Игнорирование различий API (v2 vs v3, user identification, ADF vs wiki markup)
  • Не учитывать различия в модели данных — AO (реляционная) vs Storage (key-value)
  • Копировать поведение DC один-в-один в Cloud без учёта Cloud-специфики (rate limits, timeouts)

Как используется в 2026

  • Dual-platform — маркетинговое преимущество на Atlassian Marketplace
  • Atlassian предоставляет Migration API для помощи в переносе данных DC -> Cloud
  • Крупные вендоры (Tempo, Xray, ScriptRunner) поддерживают обе платформы
  • Тренд: DC как legacy support, Cloud как primary платформа для новых фич

На собеседовании: покажите зрелое архитектурное мышление. Dual-platform = два отдельных проекта с общей бизнес-логикой, а не один универсальный. Java shared library для бизнес-правил, адаптеры для каждой платформы. Feature parity — осознанный выбор, не все функции воспроизводимы на обеих платформах.