Clean Architecture

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.ArrayList;
import java.util.Currency;
import java.util.List;
import java.util.Objects;
import java.util.UUID;

public class Main {

    // --- VALUE OBJECT ----------------------------------------------------
    // No identity of its own; two Moneys with the same amount+currency ARE equal.
    // Java records give you immutability and value-equality for free.
    public record Money(BigDecimal amount, Currency currency) {
        public Money {                                  // compact constructor = validation
            Objects.requireNonNull(amount, "amount");
            Objects.requireNonNull(currency, "currency");
            if (amount.signum() < 0) throw new IllegalArgumentException("amount < 0");
        }
        public static Money of(String amount, String code) {
            return new Money(new BigDecimal(amount), Currency.getInstance(code));
        }
        public Money add(Money other) {
            if (!currency.equals(other.currency))       // a business rule, IN the domain
                throw new IllegalArgumentException("Cannot add " + currency + " to " + other.currency);
            return new Money(amount.add(other.amount), currency);  // returns a NEW Money
        }
        @Override public String toString() { return currency.getCurrencyCode() + " " + amount; }
    }

    // --- ENTITY ----------------------------------------------------------
    // Has a stable IDENTITY (OrderId). Two orders with the same id are the same order,
    // even if their contents differ.
    public record OrderId(String value) {
        public static OrderId generate() { return new OrderId("ORD-" + UUID.randomUUID()); }
    }

    public enum OrderStatus { PENDING, COMPLETED, CANCELLED }
    public record OrderLine(String sku, Money subtotal) {}

    // A RICH entity: identity + DATA + the BEHAVIOUR that protects its own rules.
    // This is the opposite of an "anaemic" model (data with no behaviour).
    public static final class Order {
        private final OrderId id;
        private final List<OrderLine> lines;
        private OrderStatus status = OrderStatus.PENDING;

        public Order(OrderId id, List<OrderLine> lines) {
            if (lines == null || lines.isEmpty())       // invariant enforced at the boundary
                throw new IllegalArgumentException("Order must have at least one item");
            this.id = id;
            this.lines = List.copyOf(lines);            // defensive copy -> immutable inside
        }

        public Money total() {                          // logic lives WITH the data
            return lines.stream().map(OrderLine::subtotal).reduce(Money::add).orElseThrow();
        }

        public void complete() {                        // a state transition, validated
            if (status != OrderStatus.PENDING)
                throw new IllegalStateException("Can only complete PENDING orders, was " + status);
            status = OrderStatus.COMPLETED;
        }

        public void cancel() {
            if (status == OrderStatus.COMPLETED)
                throw new IllegalStateException("Cannot cancel a completed order");
            status = OrderStatus.CANCELLED;
        }

        public OrderId id() { return id; }
        public OrderStatus status() { return status; }
    }

    public static void main(String[] args) {
        // Money is immutable and validates itself.
        Money total = Money.of("79.99", "USD").add(Money.of("29.99", "USD"));
        System.out.println("Two items total: " + total);                       // USD 109.98
        System.out.println("Equal by value?  " + total.equals(Money.of("109.98", "USD")));  // true

        // The Order ENFORCES its own rules — no service needed to keep it valid.
        Order order = new Order(new OrderId("ORD-001"), List.of(
                new OrderLine("KBD-1", Money.of("79.99", "USD")),
                new OrderLine("MSE-1", Money.of("29.99", "USD"))));
        System.out.println("Order " + order.id().value() + " = " + order.total() + " (" + order.status() + ")");
        order.complete();
        System.out.println("After complete -> " + order.status());             // COMPLETED

        // Try to break a rule: the domain refuses.
        try { order.cancel(); }
        catch (IllegalStateException e) { System.out.println("Refused: " + e.getMessage()); }
        try { new Order(OrderId.generate(), List.of()); }
        catch (IllegalArgumentException e) { System.out.println("Refused: " + e.getMessage()); }
    }
}

Two items total: USD 109.98
Equal by value?  true
Order ORD-001 = USD 109.98 (PENDING)
After complete -> COMPLETED
Refused: Cannot cancel a completed order
Refused: Order must have at least one item

// APPLICATION layer. It depends ONLY on the domain (never on Spring, JDBC, HTTP).
// It defines INPUT ports (what callers may do) and OUTPUT ports (what it needs
// from the outside world), then wires them together in a use case.
//
// === Output ports — interfaces the use case CALLS ===================
package com.myapp.application.port.out;

import com.myapp.domain.model.Order;
import com.myapp.domain.model.OrderId;
import java.util.Optional;

// "I need somewhere to load and store orders" — but NOT a database. An interface.
public interface OrderRepository {
    Optional<Order> findById(OrderId id);
    void save(Order order);
}

// ---------------------------------------------------------------------
package com.myapp.application.port.out;

import com.myapp.domain.model.Money;

// "I need to take a payment" — not Stripe, not PayPal. Just the capability.
public interface PaymentPort {
    void charge(Money amount, String paymentMethod);
}

// === Input port — the use case the OUTSIDE world is allowed to call ==
package com.myapp.application.port.in;

import com.myapp.domain.model.OrderId;
import java.util.List;

public interface PlaceOrderUseCase {
    OrderId place(List<String> skus);
}

// === Use case implementation — orchestration only ====================
package com.myapp.application.usecase;

import com.myapp.application.port.in.PlaceOrderUseCase;
import com.myapp.application.port.out.OrderRepository;
import com.myapp.application.port.out.PaymentPort;
import com.myapp.domain.model.Order;
import com.myapp.domain.model.OrderId;
import java.util.List;

public class PlaceOrderService implements PlaceOrderUseCase {
    private final OrderRepository orders;     // depends on the PORT (interface)...
    private final PaymentPort payment;        // ...never on a concrete adapter.

    // DEPENDENCY INVERSION: the high-level use case and the low-level adapter
    // BOTH depend on these interfaces. The arrow points inward, toward the app.
    public PlaceOrderService(OrderRepository orders, PaymentPort payment) {
        this.orders = orders;
        this.payment = payment;
    }

    @Override
    public OrderId place(List<String> skus) {
        // 1) Build the domain object (it validates its own invariants).
        Order order = buildOrder(skus);
        // 2) Charge through the payment PORT — real impl decided at startup.
        payment.charge(order.total(), "card");
        // 3) Persist through the repository PORT.
        orders.save(order);
        // 4) Hand back just the identity. No JPA entity, no HTTP type leaks out.
        return order.id();
    }

    private Order buildOrder(List<String> skus) { /* map skus -> OrderLines */ return null; }
}

// 🎯 YOUR TURN — make the dependency arrows point the right way.
//
// The DEPENDENCY RULE: source code dependencies point INWARD only.
//   presentation -> application -> domain   (allowed)
//   domain -> infra                         (FORBIDDEN)
//
// Fill in the blanks marked with ___ so the imports obey the rule.

// File: domain/model/Order.java  (the innermost layer)
package com.myapp.domain.model;

// 1) The domain may ONLY import other domain code. Which package is safe here?
import com.myapp.___.model.Money;   // 👉 domain (NEVER infra or application)

public final class Order { /* ... pure business logic ... */ }


// File: application/usecase/PlaceOrderService.java
package com.myapp.application.usecase;

// 2) The use case depends on the PORT, not the concrete adapter.
//    Import the interface, not JpaOrderRepository.
import com.myapp.application.port.out.___;   // 👉 OrderRepository (the interface)

public class PlaceOrderService { /* depends on the interface only */ }

// ✅ Expected: domain imports only "domain"; the service imports the PORT
//    interface "OrderRepository", never the concrete "JpaOrderRepository".

// INFRASTRUCTURE layer. Adapters live on the OUTSIDE. They IMPLEMENT the ports
// the use case declared, so you can swap them without touching domain or app.
// This is the only layer allowed to mention Spring, JPA, Stripe, Kafka...
package com.myapp.infra.persistence;

import com.myapp.application.port.out.OrderRepository;   // implements the inner port
import com.myapp.domain.model.Order;
import com.myapp.domain.model.OrderId;
import org.springframework.stereotype.Repository;
import java.util.Optional;

@Repository                                               // framework annotation: fine HERE
public class JpaOrderRepository implements OrderRepository {
    private final SpringDataOrderRepo db;

    public JpaOrderRepository(SpringDataOrderRepo db) { this.db = db; }

    @Override public Optional<Order> findById(OrderId id) {
        // Map the PERSISTENCE row -> the DOMAIN entity at the boundary.
        return db.findById(id.value()).map(OrderMapper::toDomain);
    }

    @Override public void save(Order order) {
        db.save(OrderMapper.toEntity(order));            // domain -> row, also at the boundary
    }
}

// --- a second adapter for the payment port ---------------------------
package com.myapp.infra.payment;

import com.myapp.application.port.out.PaymentPort;
import com.myapp.domain.model.Money;
import org.springframework.stereotype.Component;

@Component
public class StripePaymentAdapter implements PaymentPort {
    @Override public void charge(Money amount, String method) {
        // The real Stripe SDK call lives here. The domain neither knows nor cares.
    }
}

// === ArchUnit — turn the dependency rule into a FAILING test =========
package com.myapp;

import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.lang.ArchRule;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;

@AnalyzeClasses(packages = "com.myapp")
class ArchitectureTest {
    // The domain must not reach outward to infra or presentation.
    @ArchTest static final ArchRule domain_is_pure =
        noClasses().that().resideInAPackage("..domain..")
            .should().dependOnClassesThat()
            .resideInAnyPackage("..infra..", "..presentation..");

    // The application layer must not depend on Spring.
    @ArchTest static final ArchRule application_is_framework_free =
        noClasses().that().resideInAPackage("..application..")
            .should().dependOnClassesThat()
            .resideInAPackage("org.springframework..");
}
// If anyone imports infra from the domain, "mvn test" goes red. Guard, not guideline.

// 🎯 YOUR TURN — add an OUTPUT port and an ADAPTER for sending email.
// The use case must not know about SMTP — only the capability "notify".

// File: application/port/out/NotificationPort.java
package com.myapp.application.port.out;

// 1) Declare the CAPABILITY the use case needs, as an interface.
public ___ NotificationPort {            // 👉 a port is an interface
    void orderShipped(String email, String orderId);
}

// File: infra/email/SmtpNotificationAdapter.java
package com.myapp.infra.email;

import com.myapp.application.port.out.NotificationPort;

// 2) The adapter IMPLEMENTS the port. This is where SMTP details live.
public class SmtpNotificationAdapter ___ NotificationPort {   // 👉 implements the port
    @Override
    public void orderShipped(String email, String orderId) {
        // real javax.mail / SMTP call goes here — invisible to the application
        System.out.println("Email to " + email + ": order " + orderId + " shipped");
    }
}

// ✅ Expected: NotificationPort is an "interface"; the adapter uses
//    "implements NotificationPort". Swap SMTP for a fake in tests with no
//    change to the use case.

# Recommended package layout. Read it INSIDE-OUT: domain has zero
# dependencies, then application, then the outer adapter layers.

src/main/java/com/myapp/
├── domain/                # The core. Knows nothing about the outside world.
│   ├── model/             #   Entities + Value Objects (Order, Money, OrderId)
│   ├── event/             #   Domain events (OrderPlaced, OrderCancelled)
│   └── exception/         #   Domain exceptions (OrderNotFoundException)
├── application/           # Use cases. Depends on domain ONLY.
│   ├── port/
│   │   ├── in/            #   Input ports  — use-case interfaces (driving side)
│   │   └── out/           #   Output ports — repo/gateway interfaces (driven side)
│   └── usecase/           #   Use-case implementations (orchestration only)
├── infra/                 # Adapters that IMPLEMENT the out ports.
│   ├── persistence/       #   JPA repositories + mappers
│   ├── payment/           #   Stripe / PayPal adapters
│   └── messaging/         #   Kafka producers / consumers
└── presentation/          # Adapters that CALL the in ports.
    ├── rest/              #   @RestController, request/response DTOs
    └── config/            #   Spring @Configuration — wires ports to adapters

// 🎯 MINI-CHALLENGE: design a "cancel order" use case, clean-architecture style.
// Write it from the outline — no filled-in logic given this time.
//
// Layers to touch (point every dependency INWARD):
// 1. domain/model/Order      — add a cancel() method that throws if already shipped.
// 2. application/port/out/    — reuse OrderRepository (findById + save).
// 3. application/port/in/     — define CancelOrderUseCase { void cancel(OrderId id); }
// 4. application/usecase/     — CancelOrderService implements CancelOrderUseCase:
//        a) load the Order via the repository PORT (throw if not found),
//        b) call order.cancel()  (the DOMAIN enforces the rule),
//        c) save the Order via the repository PORT.
// 5. infra/                   — keep the existing JpaOrderRepository adapter; no change.
//
// Rules to respect:
//   - The service depends on INTERFACES only (no JpaOrderRepository import).
//   - No Spring / JPA annotations in domain or application.
//   - The cancellation RULE lives in Order, not in the service.
//
// ✅ Expected behaviour:
//   cancel(existingPendingId) -> order.status() becomes CANCELLED, saved once.
//   cancel(shippedId)         -> IllegalStateException from the domain.
//   cancel(unknownId)         -> OrderNotFoundException from the service.

// your code here