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 SBCE and how does it store specifications in a Java project?
SBCE, pronounced 'space,' is a spec-driven development workflow created by Adam Bien built around the Boundary-Control-Entity (BCE) architectural style. Each Business Component keeps its specification inside package-info.java as Markdown Javadoc, requiring Java 23 or later, so the spec lives in the same package as the code rather than in a separate document tree. Developers wiring specs into their codebase can track workflow ideas like SBCE and living specifications on daily.dev.
How does SDD4J handle Java projects that don't use Boundary-Control-Entity architecture?
SDD4J introduces architecture adapters so a Business Component's boundary can be located differently depending on the project's existing structure - using the BCE structure directly in BCE projects, the feature package in package-by-feature projects, or a custom mapping strategy when a capability is spread across multiple technical packages in package-by-layer projects. This lets brownfield Java projects adopt living specifications without reorganizing first. Teams adapting spec-driven workflows to brownfield Java architectures can follow tooling like SDD4J on daily.dev.
How are testable requirements written in EARS-style format for a Business Component in SDD4J?
Requirements are phrased as observable, testable statements rather than vague goals, for example: 'When a checkout is requested for an empty cart, the Business Component shall reject the request.' Each requirement gets a stable identifier linking it to code and tests, and SDD4J's setup command lets a project configure the language used for these requirements, such as writing them in Portuguese for a PT-BR project. Engineers formalizing agent-driven Java specs with EARS-style requirements can explore related workflows on daily.dev.