// the find
idugalic/digital-restaurant
DDD. Event sourcing. CQRS. REST. Modular. Microservices. Kotlin. Spring. Axon platform. Apache Kafka. RabbitMQ
A teaching repo showing DDD, CQRS, and event sourcing applied to a food delivery domain using Axon Framework, Kotlin, and Spring Boot. It demonstrates the same domain modeled six different ways — monolith to microservices, REST to WebSockets — so you can compare architectural tradeoffs side by side. Target audience is developers trying to understand how these patterns actually fit together, not teams building production software.
The six application variants (monolith-1/2/3, microservices-1/2.1/2.2/3) let you directly compare how the same domain behaves under different messaging and deployment strategies — that's genuinely useful for learning. The bounded context modeling is done correctly: each subdomain has its own Order aggregate variant (CustomerOrder, CourierOrder, RestaurantOrder) rather than a shared god object. Using Kotlin `internal` modifier plus ArchUnit tests to enforce package-level encapsulation is a clever workaround for Kotlin lacking Java's package-private visibility. The README honestly explains why it uses the conformist context-mapping pattern and what you'd need to change to get proper consumer-driven contracts.
Last meaningful update was 2024, and Axon has had significant API changes — there's a real chance the build is broken or the patterns shown are now outdated against current Axon 4.x. The shared strongly-typed event classes across all bounded contexts (drestaurant-core-api) directly contradict what the README says about published language and loose coupling — the README admits this but calls it 'demo' behavior, which makes it a bad model to copy. H2 as the event store in most examples means you lose the durability guarantees that make event sourcing worth the complexity. No Docker Compose or setup script, so getting all six variants running with Kafka, RabbitMQ, and AxonServer simultaneously requires nontrivial manual work.