Vernac 0.4.0

Model reusable domain capabilities, expose practical application APIs and keep the language of the business visible beside its executable model.

Reuse a domain capability through Maven

Versioned Vernac modules publish explicit exports in .vmodule definitions and carry data-only contracts with their compiled Java implementation. Consumers import exported types by their original namespace. Compatibility checks distinguish public contract changes from private implementation noise and preserve module documentation.

Applications compose executable modules in .vapplication files. Explicit activation, required-module checks and fixed/profile-dependent outbound bindings make provider selection deliberate. Persistent modules retain separate migration histories; startup coordinates dependencies before application migration. Their operations participate in the application’s REQUIRED transaction. See the module lifecycle tutorial.

Return a page, not an entire database

Repositories support offset, counted offset and cursor pagination over ordered domain lists. Results still contain complete aggregates. Typed requests and traversal helpers keep pagination calculations out of application behavior; optional counts support page navigation. Usecase Results and HTTP DTO mappings preserve independent page components and their metadata. Dispatch demonstrates a paged board API.

A type may declare multiple lists and sets, each with its own name and behavior. See pagination and collections.

Explain failures at the HTTP boundary

Inbound adapters support ordered declarative error policies at endpoint and adapter scope. Typed rejection codes and integration responsibility/category selectors map to explicit public status/code/message replies. Technical context remains available to application diagnostics without automatically exposing external responses or exception messages. See inbound HTTP.

Make the model’s meaning visible

Namespaced term declarations capture descriptions, examples and notes, including quoted concepts with spaces. Exact-name type documentation appears in hover, generated JavaDoc and readable/machine-readable glossaries. Exported module types retain that documentation in consuming applications.

The new vernac:diagram goal exports Mermaid, PlantUML, Markdown and JSON per namespace. IntelliJ’s Show Domain Diagram action includes unsaved source snapshots and opens the Markdown view. Mermaid preview support must be enabled in the IDE. Diagrams show declared relationships and vocabulary; they do not guess runtime calls or event flow. See ubiquitous language and domain diagrams.

Requirements and upgrade notes

• Use matching compiler, runtime and IntelliJ plugin 0.4.0 versions after publication.
• Build Vernac/plugin sources with JDK 25; generated applications target Java 21. Release automation pins Maven 3.9.16; database examples use PostgreSQL 17.
• Source examples default to 0.4.0-SNAPSHOT. Standalone applications declaring vernac.version select -Dvernac.version=0.4.0; example application versions are independent.
• Module metadata is module-contracts-9. Rebuild development producers and consumers together; do not assume older metadata is accepted.
• Regenerate Java and review resulting API/schema changes. Module VO changes can require migrations in both the producer and applications embedding those values. Published migrations are not rewritten; migration candidates require owner review and testing.
• Activation is explicit, not transitively inherited. Maven availability alone does not enable a module’s runtime behavior. Bind payment/network providers deliberately.

Deliberate boundaries

Authorization/capabilities, deeper cross-language refactoring/debugger integration, AI completion, asynchronous ports and additional inbound transports remain future work. Diagrams are snapshots, not an interactive model editor. Domain mutation/transaction failure does not restore Java object state. External effects retain their own retry and idempotency requirements. Migration replay on disposable databases is not a guarantee for production data, locking or deployment compatibility.

Publication and acceptance evidence belongs in the GitHub Release: actual source SHA, workflow run/attempt, original plugin ZIP and release.json, Central availability and Marketplace status. Do not describe pending publication or approval as completed.