jivejdon is a forum and knowledge graph built on hexagonal Java

A forum whose posts double as a knowledge graph

Jivejdon is described as a chain notebook or chain blog, a knowledge graph and a knowledge system, built with domain driven design plus domain events and event sourcing plus CQRS, on a clean or hexagonal architecture, powered by the jdonframework. The posting feature connects related posts through shared keywords and topics, organizing them into an interconnected web of knowledge. For human readers, posts appear in chronological order through a thread based view, while AI systems can explore the same content as a knowledge graph through the tag pages, which the documentation describes as a thematic garden where ideas grow and connect. The stated use is enterprise knowledge systems, and the claim about combining intelligent agents is that it can become an enterprise's second brain. The audience to keep in mind is a Java developer studying how these architectural patterns compose, because the documentation leans heavily on diagrams of the aggregate model, the use case and the package view, and the code is written to be read.

Two aggregate roots, and a rich model with private setters

The domain model section is specific about the aggregate design. There are two aggregate roots in jivejdon, FormThread and ForumMessage, described as the root message. The ForumMessage model is presented as a rich model with no public setter methods, all setters being private. Four domain model principles are listed. High encapsulation, where all members' setter methods are private by default and then internal, with a note that a heavy builder pattern is needed to create an aggregate root. High persistence ignorance, with no dependencies on infrastructure, databases or anything else, all classes being plain Java objects, and the customer and supply model from jdonframework used to separate the domain model from persistence and the repository. Rich in behaviour, with all business logic in the domain model and no leaks to the application layer. And low primitive obsession, with primitive attributes of entities grouped into value objects, MessageVO being the example, holding subject and body for the message content. The design intent is that the domain stays free of framework and persistence concerns, and the documentation is explicit that this is a deliberate structure rather than incidental.

The invoking path, from presentation down to infrastructure

The layering is described by an explicit invocation path:

presentation -> api -> domain -> spi ->infrastructure

The presentation layer talks to the api layer, the api layer talks to the domain, the domain talks through the service provider interface to the infrastructure. The presentation side is not free form, it is driven by an XML adapter, models.xml, which maps a model key and class to a handler and a service reference:

	<model key="messageId" class="com.jdon.jivejdon.infrastructure.dto.AnemicMessageDTO">
		<actionForm name="messageForm"/>
		<handler>
			<service ref="forumMessageService">

				<createMethod name="createReplyMessage"/>

			</service>
		</handler>
	</model>

The class named here is the anemic DTO, which the documentation says is where all business data outside the domain is packed, so that business rules in the aggregate root do not leak out of the domain. The api layer is a plain service interface:

public interface ForumMessageService {

	Long createReplyMessage(EventModel em) throws Exception;
	....

}

And the api service delegates to the aggregate root, with the addChild method on ForumMessage acting as a command handler under the CQRS model.

One writer, domain events, and an event store

The concurrency and persistence story is what makes the sample interesting to a backend developer. The addChild method is marked with an @OnCommand annotation, which comes from the pub-sub model of jdonframework, and that annotation makes the method a command handler able to run with a single-writer pattern, described as no blocking, no lock and high concurrency, with only one thread or process invoking that update method. The domain event named event-sourcing.addReplyMessage then sends a ReplyMessageCreatedEvent to the infrastructure layer such as the repository, which is the mechanism that separates domain logic from infrastructure and databases. That event is stored in an event store called jiveMessage, described as a message posted events table, and the documentation notes that the event can be used to reconstruct the latest replies state of a thread, with the replay logic living in ForumThreadState. The CQRS section completes the picture. Reads and writes are separated into separate models, using commands to update and queries to read, and ForumThread and ForumMessage are held in a cache that acts as a copy of the event log. When an update command activates one of those models, domain events clear the cache, and the consistency between the cache and the database is maintained by those events.

The stack, the deployment and the age of the release

The canonical deployment is described as an NginX plus Tomcat plus JDK8 plus MySQL arrangement, and the repository carries a Dockerfile.web, a pom.xml, a ddl/ directory and an application/ directory alongside src/. The project documentation is bilingual in the sense that the canonical site is linked along with a gitee mirror, and the project is described with a link to a video of the repository growing like a slime mold, which is a piece of theatre rather than a technical claim. The significant practical fact is the release history. The only listed release is 5.0, published as jivejdon-5.0-src on 2018-08-22, while the last push to the repository was on 2026-10-18 and the repository is not archived. So the code is being worked on but the published artefacts are years old, and the project depends on its own jdonframework rather than on a standard application framework. The licence is Apache-2.0 with the text in license.txt, and the repository keeps a CHANGES.TXT alongside a doc/ directory holding the architecture diagrams that the project documentation references.

Where this reference implementation stops being useful

There is an obvious boundary, and it is the age of the tagged release combined with the dependency on a bespoke framework. A Java team starting a forum or an enterprise knowledge base in 2026 would not deploy this. The runtime stack described in the canonical deployment, JDK 8 with Tomcat, is two generations behind what you would use now, and the persistence is a MySQL schema described by files in ddl/ rather than by a migration tool. The event store and cache model also has a specific assumption, a single writer per aggregate, which scales differently from the multi-writer databases most teams now reach for. Where the project is genuinely valuable is pedagogical. It is a complete, small, readable application in which the domain, the api, the infrastructure and the presentation layers are all present, with the aggregate boundaries named, the command and event flow traced, and the XML adapter that wires the front end to the service shown in full. If your goal is to understand how domain events, an event store, a CQRS read model and a hexagonal boundary fit together in code that actually runs, reading this repository is faster than assembling the same understanding from diagrams. If your goal is a production system, the jdonframework dependency and the 2018 release tag are reasons to look elsewhere.

Editorial conclusion

Adopt jivejdon if you want a working reference for DDD, CQRS and event sourcing in Java with hexagonal layering, and you are happy to read the source to learn from it. Do not adopt it as the basis of a new production forum, since the last tagged release is 5.0 from 2018 and the project depends on its own jdonframework. Before you start, read the package view and the models.xml adapter to understand the layering, and check that the JDK and MySQL versions in the canonical deployment still match your environment.

Frequently asked questions

Official sources

1. banq/jivejdon on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases