// the find
banq/jivejdon
Jivejdon is a chain notebook with DDD/CQRS/Clean architecture
A Java forum application that demonstrates DDD, CQRS, and event sourcing patterns on top of the author's own jdonframework. If you want to see aggregate roots, domain events, and CQRS read/write separation in a working codebase rather than a toy example, this is one of the few Java repos that actually tries to do it correctly. The 'knowledge graph' and 'enterprise second brain' framing is marketing; it's a threaded forum with good architecture.
- The aggregate root implementation is genuinely correct: private setters, builder pattern for construction, no infrastructure types leaking into the domain model. ForumMessage is the kind of rich entity DDD books describe but most codebases never actually build.
- The CQRS read model is pragmatic — cache is the query side, domain events invalidate it. No separate read database to operationalise, no eventual consistency lag to explain. Simple and it works.
- The event sourcing via SQL projection is a clever middle ground: ORDER BY modifiedDate DESC reconstructs the latest state without a full event replay engine, and count(*) gives reply totals. Avoids the complexity of a proper event store for a use case that doesn't need it.
- 15+ years of active development (last push yesterday) means real edge cases have been discovered and fixed. This is not a demo that was abandoned after the blog post.
- jdonframework is load-bearing and underdocumented. The @OnCommand annotation, the customer/supply pub-sub model, the EventDisruptor wiring — none of this is standard Java. You cannot study the DDD patterns here without also reverse-engineering a custom framework with minimal English documentation.
- The tech stack is two generations behind: Struts + JSP, Tomcat 7, JDK 8, MySQL 5.6 in the Docker setup. Ignore the presentation layer entirely — it adds no signal.
- The event sourcing is shallow. No event versioning, no snapshot strategy for threads with thousands of replies, no tooling to rebuild projections. It would fall apart under any serious write load without significant rework.
- XML-heavy configuration throughout (struts-config-forum.xml, models.xml, myaspect.xml) makes the wiring between layers opaque without running the application. Reading the architecture from the code alone requires jumping between a dozen config files.