# Integrate DSM into an Application

## When to use

Use this task when adding DSM to a Java or Spring Boot application or consolidating scattered raw collection calls.

## Inspect first

- Locate domain ports, assembly, configuration sources, lifecycle, and existing integration tests.
- Inspect locator, entity, codec, schema, and communication-domain identity.
- Read [domain adaptation](/en/15-domain-adapter.html) and [Spring assembly](/en/16-spring-boot.html).

## Required inputs

Obtain domain actions, state classification, collection selection, namespace, serialization contract, failure propagation, and test environment.

## Implementation path

1. Keep the business layer dependent on a domain port rather than DSM locators.
2. Create the runtime and typed collections in an adapter or composition root.
3. Validate properties, codecs, schemas, and collection registration during startup.
4. Define the order for `RUNNING`, readiness, freeze, and close.
5. Establish E1 fake, E2 one-process, E3 controlled multi-node, and necessary E4 real-port evidence.

## Constraints

- A fake validates the domain-port contract and does not prove DSM networking, replication, or repair.
- A started Spring context does not establish multi-node behavior.
- The `tenantId/applicationId` communication domain and `collectionId` collection domain provide different isolation boundaries.

## Failure patterns

- Reconstructing locators throughout business services.
- Delaying startup configuration errors until runtime.
- Reporting success when zero tests ran or relevant tests were skipped.

## Validation

Run domain-port tests first, followed by DSM adapter, Spring context, and controlled multi-node tests. Report what each layer can and cannot prove.

## Evidence

- [DSM official examples](https://github.com/leanowtech/dsm-examples/tree/0eca40d69e4ac5e01d7f82e75feec761ce1c101e)
- [Validation scopes](/agent/en/v/0.1.2/reference/validation-scopes.md)
- [Source and claim discipline](/agent/en/v/0.1.2/policies/source-and-claim-discipline.md)