concept domain in category software development

This is an excerpt from Manning's book Writing Great Specifications: Using Specification by Example and Gherkin. Login to get full access to this book.

Domain—What an organization does, and the world it does it in

The journey planners will use the jargon of their field and have limited understanding of the technical dictionary of software development. Developers, on the other hand, will understand and discuss the system in terms such as objects, methods, and design patterns. Having a single common language eliminates the cost of mental translation and reduces the number of misunderstandings—the ratio of noise in the signal—in discussions between technical and nontechnical stakeholders. Translation blunts communication and makes domain learning anemic.

Figure 11.5. An Activitee specification suite organized by domains

A bounded context is a fragment of the domain that has a unified model. A model is meaningless unless it’s logically consistent, so each bounded context must have a unified model that’s internally valid.

This is an excerpt from Manning's book Test Driven: Practical TDD and Acceptance TDD for Java Developers. Login to get full access to this book.

Granularity of the tests we write is also something to pay attention to. We strive to write just enough test code to have a failing test rather than write an epic-sized test for a piece of functionality that’ll take an hour to implement. Depending on the domain, tools, and technologies in question, writing the test might be a matter of a few seconds or it might take a couple of minutes. The implementation for a test should generally be within that time range, too. Using complex technologies might push our granularity and rhythm toward the longer end of the range, but, as we will see in part 2, most of the time all the talk about the complexity associated with stuff like Java Servlets or data access code is really just that: talk.

Figure 6.2. Data Access Object pattern: Domain objects being created, retrieved, and persisted through a Data Access Object interface without knowledge of the underlying database technology

You may have noticed that user stories as a requirements-management technique tend to stress having close and frequent interaction with the customer. If you’re worried about not having an on-site customer, or having a customer who’s not keen on having much to do with developing the software, you can stop worrying. There are ways around this obvious limitation, and we’ll talk about those later on. For now, just consider the customer as referring to a role rather than a specific person—a role that can be played by, say, one of the test engineers or developers who knows enough about the product’s domain to be able to make the kinds of decisions a real customer would make.

Use the language of the domain

An important property of acceptance tests is that they use the language of the domain and the customer instead of geek-speak only the programmer understands. This is the fundamental requirement for having the customer involved in the creation of acceptance tests and helps enormously with the job of validating that the tests are correct and sufficient. Scattering too much technical lingo into our tests makes us more vulnerable to having a requirement bug sneak into a production release—because the customer’s eyes glaze over when reading geek-speak and the developers are drawn to the technology rather than the real issue of specifying the right thing.