fixup! docs: Add requirements

Author: jeffjensen

src/site/asciidoc/requirements.adoc

@@ -55,6 +55,8 @@ Do not create a `pom.xml` at the project root.
   sorted alphabetically.
 * List every sibling module in `<dependencyManagement>` pinned to
   `${project.version}`, sorted alphabetically by `artifactId`.
+* Import the `spring-boot-dependencies` BOM in `<dependencyManagement>` (managed via a
+  `spring-boot.version` property) so Spring artifact versions are centrally managed.
 * Properties: Java 21 via `maven.compiler.release`; UTF-8 source encoding via
   `project.build.sourceEncoding`.
 * `<pluginManagement>` — declare pinned versions for `maven-compiler-plugin`,
@@ -80,10 +82,9 @@ Shared domain classes. No dependencies on other generated modules.
 
 === `common-testing`
 
-Shared test utilities.
+Shared test infrastructure.
 
 * Dependency: `common-domain`
-* No test-scope Java packages (the `src/test/java` directory is created but contains no source files).
 
 === Per integration: `domain-{type}-{name}` and `integration-{type}-{name}`
 
@@ -100,7 +101,12 @@ For each `type:name` integration entry, generate two modules
 === Per service area: `service` or `service-{name}`
 
 Business logic for a service area.
-Dependency: `common-domain`.
+Dependencies: `common-domain` and the area's own `domain-service` /
+`domain-service-{name}` module.
+
+For each service area, also generate a `domain-service` (single service) or
+`domain-service-{name}` module holding that area's domain classes
+(dependency: `common-domain`).
 
 === Per presentation tier: `domain-{type}` and `presentation-{type}`
 
@@ -116,24 +122,30 @@ For each presentation type, generate two modules
 
 Assembles the runnable artifact (e.g. Spring Boot uber jar).
 Depend on all generated modules except `acceptance-tests`, `common-testing`,
-and `app` itself.
+and `app` itself, plus `spring-boot-starter-web` and `spring-boot-starter-jdbc`.
+Contains the Spring Boot `Application` (`@SpringBootApplication`,
+`@EnableTransactionManagement`) and `AppServletInitializer` (WAR deployment)
+classes in the `.config` sub-package. `Application` `@Import`s the `@Configuration`
+class that every app-composed module carries in its own `.config` sub-package.
 
 === `acceptance-tests`
 
 Functional tests that exercise the application end-to-end.
-No main-scope Java packages (the `src/main/java` directory is created but contains no source files).
 
 * Dependencies: `app`, `common-domain`, all `domain-{type}-{name}` modules,
+  all `domain-service` / `domain-service-{name}` modules,
   all `domain-{type}` (presentation) modules.
-* Do not depend on service modules or integration implementation modules.
+* Do not depend on service (business-logic) modules or integration implementation modules.
 * Configure `maven-failsafe-plugin` with the `integration-test` and `verify` goals.
 
 [[source-structure]]
 == Source Structure
 
 Each module's source root is the package derived from the base package prompt.
-Place a `package-info.java` in each leaf package directory with a Javadoc comment
-describing the package's purpose.
+Place a `package-info.java` in each module's primary leaf package under both
+`src/main/java` and `src/test/java`, with a Javadoc comment describing the package's
+purpose; the test-side comment is prefixed with "Tests for ...". Each app-composed
+module additionally carries a `@Configuration` class in a `.config` sub-package.
 The package for each module is:
 
 [cols="1,1"]
@@ -146,6 +158,8 @@ The package for each module is:
 |`integration-{type}-{name}` |`${base.package}.integration.{type}.{name}`
 |`service`                   |`${base.package}.service`
 |`service-{name}`            |`${base.package}.service.{name}`
+|`domain-service`            |`${base.package}.domain.service`
+|`domain-service-{name}`     |`${base.package}.domain.service.{name}`
 |`domain-{type}`             |`${base.package}.domain.{type}`
 |`presentation-{type}`       |`${base.package}.presentation.{type}`
 |`app`                       |`${base.package}.app`