top of page

Address Book System with Aspect-Oriented Logging and Data Validation 
Modular Backend Architecture with Cross-Cutting Concerns via AspectJ

Executive Technical Summary

A modular Java command-line address book system that manages contact creation, updating, deletion, and searching while enforcing consistent validation, logging, and error handling through Aspect-Oriented Programming (AOP). The project demonstrates how cross-cutting concerns can be cleanly decoupled from core business logic using AspectJ, resulting in a maintainable, auditable, and extensible backend architecture. File-based persistence is used intentionally to emphasize parsing, normalization, and validation rigor rather than database integration 

Address Book System with Aspect.

Key Focus Areas: separation of concerns, aspect-oriented design, validation-first backend logic, and maintainable system structure.

System Architecture Overview

The system is organized around a clean separation between core domain logic, orchestration components, persistence utilities, and cross-cutting operational concerns implemented via aspects.

Architecture layers:

  • CLI Interface Layer: Handles user interaction and command selection

  • Controller Layer: Coordinates address book operations and delegates execution

  • Domain Layer: Contact and address models with minimal embedded logic

  • Persistence Layer: File-based load/save mechanisms with structured parsing

  • Aspect Layer: Logging, validation, exception handling, and system messaging

AspectJ weaves operational behavior around core execution points without polluting domain or controller code.

Repository Structure

The repository combines a conventional Java backend layout with an explicit AspectJ layer to isolate cross-cutting concerns. Core domain logic, validation, persistence, and user interaction are kept free of logging and interception code, which is implemented separately through Aspect-Oriented Programming.

   

address-book-aop-system/

├── src/

│   ├── main/

│   │   ├── java/

│   │   │   ├── address_book/       # Core domain logic

│   │   │   ├── address_utils/      # Parsing, formatting, storage

│   │   │   ├── io/                 # CLI interaction

│   │   │   ├── validators/         # Validation rules

│   │   │   └── utilities/          # Shared helpers

│   │   └── aspectj/

│   │       └── address_aspects/    # Logging, validation, exception aspects

│   └── test/

│       └── java/                   # Unit tests

├── data/                           # Address data files

├── log/                            # Aspect-generated audit logs

├── README.md

└── pom.xml

Core Design Decisions & Rationale

Use of Aspect-Oriented Programming

AspectJ is used to isolate cross-cutting concerns that would otherwise be duplicated across multiple classes.

Rationale:

  • Eliminates scattered logging and validation code

  • Improves maintainability and readability

  • Allows operational behavior to evolve independently of core logic

 

Modular Operation Controllers

Operations such as add, update, delete, and search are implemented as discrete components.

Rationale:

  • Narrow, testable responsibilities

  • Easier extensibility for future UI or API layers

  • Clear operational boundaries

 

File-Based Persistence Model

Contacts are stored using structured plain-text files with custom parsing and formatting utilities.

Rationale:

  • Lightweight and portable

  • Emphasizes normalization and validation discipline

  • Avoids unnecessary database complexity

 

Validation Strategy

Validation occurs both:

  • Pre-execution, via aspects intercepting operations

  • Structurally, via validator classes enforcing field rules

This layered approach prevents invalid data from entering the system.

Aspect-Oriented Cross-Cutting Concerns

Logging Aspects

  • Add, update, and delete operations are logged to persistent audit files

  • Previous values are captured during updates for traceability

 

Validation & Integrity Aspects

  • Intercept invalid operations before execution

  • Log validation failures consistently

 

Exception Handling & Notification Aspects

  • Wrap execution points to provide uniform error handling

  • Centralize user-facing messages and system notifications

This design cleanly separates what the system does from how operational concerns are handled.

Domain Model & Operation Flow

Core domain classes (ContactAddress) remain intentionally minimal.
Operational flow proceeds as:

  1. User input collected and parsed

  2. Validation aspects intercept execution

  3. Core operation executes if valid

  4. Logging and notification aspects record outcomes

  5. Persistence layer saves updated state

Validation & Data Integrity Strategy

Validation covers:

  • Required field presence

  • ZIP code and phone number formats

  • Normalized text representation

  • Safe file I/O operations

All invalid states are blocked before persistence.

Testing & Verification Approach

System correctness is verified through:

  • Manual execution scenarios

  • Inspection of audit logs for update/delete accuracy

  • Validation failure testing

  • Persistence reload checks

The architecture is structured to support future automated testing with minimal refactoring.

Tools & Technologies

  • Languages: Java, AspectJ

  • Paradigms: Object-Oriented Programming, Aspect-Oriented Programming

  • UI: Command-line interface

  • Persistence: File system with custom parsing

  • Logging: Aspect-driven file logging

  • Validation: Centralized validators + AOP interception

Outcome & Engineering Takeaways

Engineering Capabilities Demonstrated

  • Practical application of Aspect-Oriented Programming

  • Clean separation of concerns in backend architecture

  • Validation-first system design

  • Centralized logging and auditability

  • Modular, extensible operation design

  

System Qualities Achieved

  • Maintainability: cross-cutting concerns isolated from core logic

  • Correctness: validation enforced before execution

  • Traceability: comprehensive audit logs

  • Extensibility: prepared for future UI or database integration

bottom of page