Social Media Management Application

Overview

A desktop application for managing social media content from one place: composing posts, organising them into a schedule, and keeping the state of several connected accounts consistent across the interface.

Problem

Managing more than one account means repeating the same work in several places, each with a different interface. The content is effectively the same; only the destination differs. That is a data modelling problem being solved manually.

Goals

• Model a post once and target it at multiple destinations.
• Keep the domain model — posts, accounts, schedule — entirely separate from the interface that displays it.
• Survive the realities of third-party APIs: expiring tokens, rate limits and intermittent failures, without discarding unsaved work.

Approach

The application is layered. A domain layer holds the model and the rules that govern it. A service layer coordinates operations and talks to external APIs. The interface layer observes the domain and renders it, and holds no business logic of its own.

Authentication with external platforms uses OAuth 2.0 authorisation flows, with tokens stored and refreshed by the service layer so the rest of the application never handles credentials directly.

Maven manages the build and dependencies, keeping packaging reproducible.

Key implementation details

• UI-independent domain model, which made the interface replaceable and the core logic testable without one.
• Centralised token handling. Acquisition and refresh live in one place; everything else asks for an authorised client.
• Resilient outbound calls. Failures are surfaced as recoverable states rather than as exceptions that discard the user’s draft.
• Explicit scheduling state, so a post’s status is always derivable rather than inferred from side effects.

Challenges

Third-party APIs differ in nearly everything: their payload shapes, rate limits, error semantics and token lifetimes. Reconciling them behind one internal interface — without that interface degrading to the lowest common denominator — was the substantial part of the work.

What I learned

The strict separation between domain and interface was worth the extra structure. Every platform-specific irregularity ended up absorbed in one layer instead of spreading through the application.