Chapter 24. Context and Domain Language

“England and America are two countries separated by a common language.”

George Bernard Shaw

Communication requires a common language. During the collaboration in the creation of acceptance tests, a common language emerges.

Ubiquitous Language

Domain-driven design (DDD) [Evans01], refers to the ubiquitous language. The ubiquitous language involves the terms in which the customer and developers talk about a system. The language arises from explanations given by a customer or subject matter expert about the entities and processes in a system. The ubiquitous language transforms itself and becomes more refined as developers and customers discover ambiguities and unclearness.

The language evolves during the collaboration on the requirements and the tests, as shown in Chapter 6, “The User Story Technique.” Contributions to the language come from the column names in tables, the names of use cases and their exceptions, and the business rules. Each term in the language should be documented with a one-sentence description that the customer unit provides and the developer and tester units understand. The customer unit leads the terminology effort, but the developer unit can suggest that terms are unclear, ambiguous, or redundant.

For example, the triad referred to entities as customer, CD, rental, and album. They could be defined with single sentences as:

• A customer is someone to whom we rent CDs.

• An album is an artist’s release.

• A CD is a physical copy of an album that is rented.

• A rental contains the information on a CD that is rented.

You can use tables in defining the terms. For example, the discount example in Chapter 4, “An Introductory Acceptance Test,” referred to the terms Customer Type and Item Total. The Customer Type can be defined by a table, such as this.

image

Order Total might be part of a larger picture table. You might show relationships to other entities if that clarifies the picture.

image

The triad should agree not only on the meanings of the entities, but their identity and continuity. Identity is whether two entities are the same. For example, if a rental contract is reprinted, it represents the same entity as the first printout. However, a credit charge that is resubmitted may be construed as a new charge, and the customer will get double-billed. If a customer checked in two CDs within a short period, two legitimate charges could look the same. The credit processor might interpret that as a duplicate billing and reject the second.

Continuity is how long an entity should persist. If a store customer wants rental history to be completely private, a rental entity should persist only until it is complete (that is, until the customer has checked-in the CD). On the other hand, if Sam wants the rental history to determine favorite CDs for a customer so he can offer him new releases in that same genre, the rental should be persistent.

Two Domains

The applicability of a ubiquitous language could be the entire enterprise. But often, that is too big a context, so it’s just for the portion of the enterprise. (DDD refers to this as the bounded context.) So each portion of the enterprise has its own domain. Two domains may overlap if they use common resources.

Figure 24.1 is an example of overlapping domains. Both Check-Out/In System and the Accounting System use a common domain—Rental Fees and Charges. This requires that for the two domains, the customers agree on a shared language for the interface to the common one.1

Figure 24.1. A Common Domain—One-Way Interface

image

The existence of a common domain impacts the acceptance tests. In Figure 24.1, the interface between Check-Out/In and Rental Fees and Charges is one-way (output only). The acceptance tests ensure that the proper data is being created. The interface between Rental Fees and Charges and the Accounting System is one way (input only). The test doubles allow the Accounting System to be tested separate from the Check-Out/In system.

What Is a Flight?

An airline system is really large. There are reservation systems, ground operations systems, and flight operations, to name a few. The term flight is pretty common. Consider how you, the customer, think of a flight. You are going to catch a flight. Do you use the same reference whether your journey is going to be on a single plane or whether you have to transfer between planes?

The airplane you board is for a particular flight, identified by the flight number. A particular flight number can represent the same airplane traveling to many cities, only one of which you are interested in going to. For example, Flight 1000 may go to Boston, then Philadelphia, then Raleigh-Durham, then Atlanta. However, you may only be interested in the Boston to Philadelphia portion.

As an example of continuity, the association between the airplane entity and the flight entity is not persistent. You may fly on the same flight number multiple times and get a different airplane.

Each part of an airline system may use the term flight in its own domain context. For some parts, a flight represents the entire travel of a physical airplane through its entire day. For others, it represents the route of an entity identified by a flight number, regardless of what physical airplane is flying it.

To keep some degree of commonality, there is an agreed-upon term for the portion between a single takeoff and the subsequent landing: a leg. When airline systems communicate with each other, they can communicate about this common entity. For example, a leg is Flight 100 from Boston to Philadelphia.

Summary

• From collaboration on acceptance tests, a ubiquitous language emerges.

• Tests should be written using the ubiquitous language.

• Multiple systems using a common system need to agree on a ubiquitous language for that common system.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.119.170