Domain layer

As explained in BDD in Action, Second Edition

A domain layer is the architectural layer of a test automation system that models the activities required to complete specified business workflows.

A domain layer is the middle layer of a test automation system. It models the exact activities required to complete workflows expressed in the Specification layer and gives sequences of lower-level activities a business meaning. section 14.2.1 section 14.4

The layer separates what an external actor is trying to accomplish from how a specific interface makes it happen. Domain activities use Serenity/JS Screenplay Pattern APIs, while the Integration layer translates them into browser, HTTP, or other interface interactions. section 14.2.1 section 15.1

A useful separation of responsibilities is:

• Keep workflows, business rules, and usage examples in the Specification layer, where stakeholders can understand them. section 14.2.1
• Model meaningful actor activities in the Domain layer instead of exposing sequences of clicks, form entries, or HTTP requests. section 15.1
• Place interface-specific interactions, test-tool integration, interactable elements, test data, and reporting in the Integration layer. section 14.2.1

Booking a plane ticket

A domain model describes a traveler searching for a flight, adjusting a departure date, filling out registration details, and selecting the cheapest flight. The underlying clicks, field entries, and HTTP requests remain implementation details of the Integration layer. section 15.1

Figure 14.15 Layers of a typical test automation system based on Serenity/JS, with their contents

Use the layer diagram to locate the Domain layer between stakeholder-facing specifications and technology-facing integrations. section 14.2.1

How BDD in Action, Second Edition covers it

How deep it goes

Introduces abstractions and their layering, but leaves interface-specific interactions to the Integration layer.

Examples

Uses traveler actions such as searching flights, adjusting dates, completing registration, and selecting the cheapest flight.

What it assumes

Assumes workflows are identified in the Specification layer and delegates external-interface details to the Integration layer.

What you can do after

Build business-meaningful acceptance workflows without coupling specifications directly to interface-specific tools.

How it connects

Connects the Specification layer, Integration layer, Screenplay Pattern, acceptance tests, and business domain.

liveBookmanning.com

Read BDD in Action, Second Edition on liveBook Get the book at manning.com

Related concepts

• multi-tier applicationpart of · A multi-tier application is an application organized into distinct tiers that separate responsibilities and interact through defined dependencies or interfaces.
• automation solutionpart of · An automation solution is a supporting system that integrates automated tests, execution frameworks, libraries, environments, and glue code to verify another system’s behavior.
• domain conceptuses · A domain concept is an idea, entity, action, rule, or other meaningful element of a problem or business domain represented in software.

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.