top of page

Art Inventory & Transaction Management System 
Modular Backend Architecture with File-Based Persistence and Automated Testing

Executive Technical Summary

A Java-based desktop system for managing art inventory, customers, and purchase transactions for a small gallery or art business. The system emphasizes precise domain modeling, deterministic pricing and shipping logic, strict validation through custom exceptions, and reliable file-based persistence validated through comprehensive automated testing. While a Swing UI is included, the primary engineering focus is on backend correctness, data integrity, and maintainable system architecture.

  

Key Focus Areas: domain-driven design, modular backend services, persistence reliability, and testable business logic.

System Architecture Overview

The system follows a layered architecture that cleanly separates domain models, service managers, persistence mechanisms, and user interface components.

Architecture layers:

  • UI Layer (Swing): Panels for inventory, customer, and transaction workflows

  • Service / Manager Layer: Inventory, customer, and transaction orchestration

  • Domain Layer: Art, Customer, Address, and Transaction models

  • Utility Layer: Validation, formatting, ID generation, and directory management

  • Persistence Layer: File-based serialization and reconstruction

This structure ensures backend services remain reusable and extensible regardless of UI implementation.

Repository Structure

The repository is organized around a layered backend architecture that separates domain models, transaction processing, validation, persistence, and orchestration logic. This structure supports deterministic pricing, robust validation, and end-to-end transaction workflows while maintaining clear architectural boundaries.

​

art-inventory-transaction-management-system/

├── src/

│   ├── main/

│   │   └── java/

│   │       ├── art/                # Artwork domain models

│   │       ├── customer/           # Customer entities

│   │       ├── transaction/        # Transaction processing

│   │       ├── manager/            # Inventory and transaction managers

│   │       ├── exception/          # Domain-specific exceptions

│   │       ├── persistence/        # File-based storage utilities

│   │       └── util/               # Validation and helpers

│   └── test/

│       └── java/                   # Unit and integration tests

├── data/                           # Inventory, customer, transaction data

├── README.md

└── pom.xml

Core Design Decisions & Rationale

Strongly Typed Domain Modeling

The art domain is modeled using an abstract Art base class with concrete subclasses:

  • Painting — dimensions, style, technique, category

  • Drawing — style, technique, category

  • Print — edition type and category

  • Sculpture — material and weight

Each subclass encapsulates its own pricing and shipping logic, ensuring business rules remain localized and extensible.

​

Deterministic Pricing & Shipping Logic

Transaction pricing is computed as:

  • Base art price

  • Plus type-specific shipping and surcharge rules

  • Aggregated at transaction completion time

Pricing logic is deterministic, testable, and enforced consistently across UI and persistence reloads.

​

Validation-First Error Handling

Validation is enforced at construction time and during state transitions using centralized utilities and custom exceptions.

Validation includes:

  • Art ID and transaction ID formats

  • Non-empty required fields

  • Address normalization (state, ZIP, phone)

  • Transaction invariants (customer present, at least one art item)

Invalid operations fail fast, preventing inconsistent system states.

​

File-Based Persistence with Round-Trip Safety

The system uses structured text formats to persist:

  • Inventory

  • Customers

  • Pending and completed transactions

Each domain object implements a toString() / fromString() pattern, enabling full round-trip reconstruction of polymorphic objects. Integration tests verify persistence correctness for both simple and multi-item transactions.

Domain Model & Lifecycle Logic

Item & Transaction States

Art items move through controlled states:

  • AVAILABLE → RESERVED → SOLD

Transactions progress through:

  • PENDING → COMPLETED

State transitions are enforced centrally to prevent inventory corruption and invalid transaction histories.

Service Layer Responsibilities

  • ArtInventoryManager: add/remove art, enforce uniqueness, expose inventory queries

  • CustomerManager: manage customers with lookup by email

  • TransactionManager: create, complete, query, and persist transactions

Managers encapsulate persistence concerns and expose clean APIs to the UI layer.

Testing Strategy

The project includes an extensive JUnit 5 test suite covering:

Unit Tests

  • Domain constraints and validation

  • Pricing and shipping logic

  • Serialization and parsing correctness

  

Integration Tests

  • Inventory save/load cycles

  • Customer persistence

  • Transaction creation, completion, and reload

  • Full persistence of completed transactions with multiple art items

A FullTestSuite aggregates tests to act as a regression harness when evolving the system.

Tools & Technologies

  • Language: Java

  • UI: Java Swing (presentation layer)

  • Testing: JUnit 5

  • Persistence: Plain text files (CSV-like and pipe-delimited formats)

  • Utilities: java.io, java.nio.file, Java Time API

  • Architecture: OOP with enums, custom exceptions, and service managers

Outcome & Engineering Takeaways

Engineering Capabilities Demonstrated

  • Domain-driven backend design with strong invariants

  • Modular service-layer architecture

  • Custom exception engineering and validation utilities

  • Deterministic pricing and lifecycle enforcement

  • Reliable file-based persistence with integration testing

  • Separation of backend services from UI concerns

 

System Qualities Achieved

  • Correctness: strict validation and controlled state transitions

  • Maintainability: clean modular boundaries and readable domain logic

  • Extensibility: new art types or pricing rules can be added predictably

  • Testability: comprehensive unit and integration test coverage

bottom of page