An exploration of how Spec-Driven Development can evolve into 'Living Specifications' for Java projects using AI coding agents. The piece traces a journey from Loiane Groner's spec-driven feedback loop, through the author's own SLDD skills experiment, to discovering SBCE (a workflow by Adam Bien built on the Boundary-Control-Entity architecture that stores specifications as Markdown Javadoc inside package-info.java) and finally to SDD4J, an open-source workflow the author built with Matheus Oliveira that uses architecture adapters so specifications can work across brownfield Java projects using different architectural styles (BCE, package-by-feature, package-by-layer). Requirements are expressed using EARS-style testable statements, and the workflow supports localized languages for specifications. The core argument is that specifications should live close to code, drift should be visible, and convergence between spec and implementation should be cheap, rather than treating a spec as an immutable source of truth.
Table of contents
From Spec-Driven Development to Living Specifications in Java ProjectsFrom Spec-Driven Development to Living Specifications in Java ProjectsQuestions this post answers
What is SDD4J and how does it differ from SBCE for spec-driven development in Java?
SDD4J is an open-source Agent Skills workflow that adapts spec-driven development to a Java project's existing architecture through architecture adapters, unlike SBCE which anchors specifications specifically to the Boundary-Control-Entity (BCE) architectural style. SDD4J supports package-by-feature, package-by-layer, and BCE structures without requiring reorganization, and provides setup, new, apply, and verify commands, released via the soujava/agent-skills GitHub repository. Explore daily.dev for more on choosing spec-driven workflows that fit existing Java architectures.
How does SBCE store specifications alongside Java code?
SBCE stores each Business Component's specification inside its own package-info.java file as Markdown Javadoc, requiring Java 23 or later, rather than maintaining a separate specification tree. This keeps the spec in the same structural neighborhood as the code so both developers and coding agents can find it easily, reducing the risk of specifications drifting out of sync with implementation. daily.dev helps developers track approaches like SBCE for keeping specs close to code.
What is the EARS format and how is it used to write testable requirements for AI coding agents?
EARS (Easy Approach to Requirements Syntax) is used in SBCE and SDD4J to express requirements in a structured, testable English form, such as 'When a checkout is requested for an empty cart, the Business Component shall reject the request,' rather than vague statements like 'checkout should work correctly.' Each requirement gets a stable identifier, giving coding agents a deterministic verification boundary while still leaving implementation freedom. daily.dev surfaces practical approaches like EARS for writing requirements agents can verify against.
1 Comment
Share this post