Domain Understanding

Understanding the domain involves five types of mental discipline reinforced by object thinking principles and ideas:

• Extract your understanding of the domain from the domain; use the metaphor of domain anthropology to guide this effort. The goal of software development is to create artifacts, with each artifact consisting of an admixture of hardware, software, processes, and interfaces allowing interaction with other artifacts or with people. Deciding which artifacts are needed and how they will be required to interact with existing (and planned) artifacts as well as with people is a result of understanding the domain ”as the domain is understood by its inhabitants. (See the sidebar in the next section of this chapter, Domain Anthropology and Management. )

• Decompose the problem space into behavioral objects, and make sure the behaviors assigned to those objects are consistent with user expectations. This requires understanding why users make distinctions among objects and the illusions they project on those objects. User illusions (following Alan Kay) consist of how people recognize different objects in their world and, having recognized an object, what assumptions are made about how to interact with that object and what its responses will be.

• User illusions should be maintained ; your software objects should not violate them unless you can construct a plausible alternative story that shows a different set of domain entities interacting in different ways or having different capabilities. Business reengineering involves exactly this kind of activity ”using domain language and user illusions creatively to craft new stories, some of which might lead to new software.

• Decompose your problems (applications) in terms of conversations among groups of objects. Everything of interest in the domain is currently accomplished by groups of objects (people and things). Any artifact you construct must participate in a natural way in these same groups. Perhaps your artifact is simply replacing an existing object in the domain with a computer-based simulacrum, in which case it must know how to respond to and supply some relevant subset of recognizable and intuitive interaction cues. Perhaps it is an entirely new object, in which case it will need to be socialized to conform to the existing community.

• Model your objects as simply as possible consistent with the needs of the development team (which should include users,   la XP) to communicate their collective understanding of the objects and the domain. Only after you have completed this kind of modeling should you even begin to think about how to implement any new or replacement objects your domain understanding leads you to believe are desirable.

This chapter will discuss how object thinking influences your understanding of the domain, its objects, and the models useful for clarifying and communicating your understanding. Chapter 8, Thinking Toward Design, will outline how to move toward implementation without abandoning object thinking or our understanding of the domain.

Domain understanding involves using another metaphor, domain anthropology, to provide the mental perspective used when discovering objects and their interactions. The same perspective is useful for identifying and assigning discrete services to specific objects. A number of heuristics can be employed to facilitate object discovery and definition. I will now discuss each of these factors in turn .

Domain Anthropology

The software developer must confront a strange world with the goal of understanding that world in its own terms. A close approximation of this task is the work of a cultural anthropologist confronting a strange (to her or him) society. Domain anthropology provides a very useful metaphor ”providing both cautions and insights that will guide the application of object thinking to the early phases (requirements definition, object identification) of development. Software expertise does not trump domain expertise. The longer a software developer works in a domain, the more effective her software work will be.

I begin with a caution: anthropologists have their own culture ”with its associated explanations , values, assumptions, and so forth ”and they must zealously guard against the mistake of interpreting everything in the new society in terms of their own (often unconscious) culture and values. This kind of cultural relativism should be respected ”the software developer does not have a special viewpoint that allows him to judge or alter the culture he is working with.

Software developers, on the other hand, are fair game for evangelistic efforts. Most developers are steeped in the way of the computer, with abundant assumptions about how a computer works and the best ways to make a computer perform its tricks. You could say that developers have internalized a culture of computing. The fact that this book ”as well as the object and XP movements in general ”is trying to change developer culture does not imply that developers have a corresponding right to change user or organizational cultures. Developers, traditional or reformed, must set aside their professional culture (just as the anthropologist sets aside his or her birth culture) before they attempt to understand users and user domains. Following this injunction is inconsistent with the goals and intents of the stereotypical computer geek who has invested a lot of time and energy to think like a computer.

Note  

To be totally honest, this book is attempting to influence more than just the culture of software developers. To begin with, I hope it affects all members of an XP development team, which includes both users and managers, and that it promotes change of the organizational culture-at-large in ways that make it more amenable to iterative, extreme object development. Even more grandiose hopes fill my mind from time to time ”that I will make a small contribution to a movement that redefines software as a craft performed by human beings on behalf of other human beings. Beneath the staid exterior of the practitioner-academician beats the heart of a wild-eyed evangelist.

A developer attempting to understand a new application or problem domain is not unlike an anthropologist confronting a new culture for the first time. She is surrounded with experts in that domain, but they speak and act in strange ways that she needs to understand. You need to learn from them how they view and make sense of their world.

Note  

As an anthropologist and an outsider, you do have a perspective that the domain experts lack. Much of what the domain experts actually do and think about is invisible to them in the same way that a human is rarely aware of the culture to which he or she belongs. You will be able to observe important aspects of the domain that the experts will fail to report to you or talk about because they are so obvious that they are below the threshold of consciousness. But do not confuse this kind of objectivity with projections of your own cultural values (computer knowledge) onto the domain you are supposed to be observing.

When a cultural anthropologist confronts a new culture, the first task (after allaying suspicion and obtaining some kind of rapport) is to learn the language. The object developer needs to learn the names of things in the domain that have been accorded object status by the natives ”made distinct from the domain and from other things in the domain ”by virtue of having been given a name . Naming things is how domain experts (and the indigenous peoples studied by the cultural anthropologist) naturally decompose their domain.

Note  

Software developers must also allay suspicion and establish rapport. An anthropologist does this in two ways, by convincing the natives that he is basically harmless and an amusing curiosity and by being a source of minor valuables ”services such as a ride, small amounts of money, or goods desired by the people he is studying . These techniques work reasonably well if the people do not have extensive experience with anthropologists. They don t work very well when there is an adverse history of interactions. Native American people, for example, are extremely leery of anthropologists (excepting sometimes anthropologists that are also Native American) because they have been exploited too many times in too many ways. The world of software suffers from this same kind of adverse history. The whole reason there is so much emphasis on requirements and specifications is to provide the basis for a contract between two groups that basically distrust each other. Perhaps the most useful pointers and techniques for overcoming this mistrust can be found in the work of Larry Constantine and even the domain-driven design ideas advanced by Eric Evans.

Most books and methods addressing how to do object development recommend that the object discovery process begin with underlining the nouns (names) in a domain or problem description. While it is true that many of those nouns will indeed turn out to be viable objects, it is unlikely that any written description will be sufficiently complete or accurate to meet the needs of domain anthropology. Cultural anthropologists do not base their understanding of a culture solely on written reports by people in that culture. They go and live with the people, observe them, and talk with them. Domain anthropologists must do the same thing.

Domain Anthropology and Management

Anthropological investigation of a culture is not an easy task. The anthropologist will spend months, if not years , preparing to go to the field. That preparation includes digesting all that is already known about the target culture (and other similar cultures) as well as techniques for observation and information elicitation . Once in the field, the anthropologist will spend a minimum of a year, optimally two years, living and interacting with the people he is studying.

A domain anthropologist should do no less! Observation for a complete business cycle (including the annual financial cycle), which includes the major events and rituals (new employee to company picnic) that occur in the domain, will yield important information relevant to the design and success of any new software system.

However, management is unlikely to provide the necessary time for this kind of activity ”at least not as overhead for any single project ”if domain anthropology is seen as a new phase of software development that must be completed up-front before any code is written. XP, fortunately, builds domain anthropology into its practices. Early and frequent releases, short feedback cycles, and open communication all work together to simulate the participant/observation experience of a domain anthropologist. As with the anthropologist, these activities begin with fairly simple day-to-day activities (and the new software to support them) and evolve , as the developers gain experience with the domain, into more sophisticated systems. There are other parallels, such as the on-site customer playing a role quite similar to that of the cultural informant relied upon by anthropologists.

 

Given that management will likely not allow time for a complete ethnography, some kind of conversation about the domain with both users and developers participating is desirable. Constructing a semantic net (see Chapter 6, Method, Process, and Models ) is a useful way to gather information about potential objects and expectations of those objects. While constructing this net, the domain anthropologist must operate , somewhat, as if she were a naive child ”constantly asking

        What is this?

        Why is this considered to be a ______?

        How do you distinguish between this and that?

        Why?

The answers to these questions not only reveal potential objects but also start to reveal the expectations that domain experts have of those objects. Begin the object discovery via the semantic net technique by asking for one or two sentences about the domain in general, such as two sentences that describe what your company/department/team does. Select a couple of nouns and verb phrases, and write the first elements of a semantic net (see Figure 7-1) on a whiteboard. Ask everyone present to brainstorm new elements (circles, nouns) and new connections (arcs, verb phrases). This exercise should be a stream of consciousness ”brainstorming ”session, with analytical discussion to follow later.

Figure 7-1: A partial semantic net for a subsidized mortgage company.

It usually takes but a short period of time, five to ten minutes, to produce a fairly large diagram. The circled nouns provide a rich set of potential objects, and the relationships provide an equally rich set of potential responsibilities (expectations of those objects). This semantic net can then be placed on the wall as a common reference point as the discussion proceeds to more detailed levels.

Subsidized Mortgage Company

The partial semantic net in Figure 7-1 is based on the following conversation about a company that provides subsidized mortgages to qualified couples.

Please give me a brief description of your company.

Our company provides mortgages to qualified couples, subsidizes monthly mortgage payments when necessary, collects payments, invests whatever capital is not tied up in mortgages, and otherwise manages its assets. (This yields an initial net consisting of bubbles for mortgage, couple, payment, investment, and asset. Initial arcs include investment is_an asset, couple receives mortgage.)

I assume the mortgage is for a home?

Yes, a home that must have a purchase price less than or equal to the median price of all homes in its neighborhood. Oh, and the home cannot have a purchase price greater than $100,000.

What qualifies a couple for a mortgage?

Couples must have been married for at least 1 year, but not more than 10, and be gainfully employed. They will not have the required 10 percent down payment required by other lenders, and the monthly payments on a $90,000 mortgage will exceed 28 percent of their joint gross income.

What do you mean by gainful employment?

At the time of application, proof must be submitted of full-time employment for at least 48 of the previous 52 weeks.

We also have to have funds available that are sufficient to cover the mortgage.

How do you know if you have funds available?

We calculate our expected income from investments and divide by 52 (we calculate available funds weekly); we figure our annual operating expenses and divide by 52; we total weekly income from mortgage payments (oh yes, we also collect mortgage payments weekly); and we calculate any grants we expect to give out this week. Expected annual income from investments is calculated and divided by 52 and added to the pool of funds. We then compare the cost of the mortgage or mortgages applied for with the amount of money in the pool and fund all we can. Any leftover money is invested.

People have to apply for the mortgage? (Note the naive question.)

Of course they fill out an application, and when the information on the application is verified , the application is deemed fundable. If we have money, we grant the mortgage and the application is given funded status. If we do not have the money this week, the application stays fundable until it is funded or some other event causes it to be canceled .

 

One reason for reducing the object discovery process to simple questions and observations is to eliminate preconceptions. If a cultural anthropologist were to begin an analysis of kinship with the preconception that everyone lives in a nuclear family (mother, father, and 2.5 children) and that everyone practices monogamy, her analysis of human kinship patterns would be so incomplete and distorted that it would be worthless.

An analogous result will occur if the domain anthropologist begins her task with preconceptions about data, functions, processes, how things must be implemented in COBOL, or how computers work. These preconceptions about implementation will blind the domain anthropologist to what is going on in the domain and what is required of the new software artifact. For instance, a software expert is likely to see any kind of form as an ordered collection of static text objects and entry field objects because that s the way that a form will be implemented. If this knowledge disposes the expert to ask users only those questions dealing with choices of text and entry fields and the values that can be placed in an entry field, the expert will miss potentially important behavioral requirements. Behavioral requirements for a form might include identifying itself, modifying itself, presenting itself (with the implication of multiple views), completing itself (making sure every entry field contains appropriate values), and validating itself. These are behaviors that will not be discovered by asking about contents.

The initial focus of domain anthropology is on identifying stories and some potential objects in the domain. Stories reveal both potential objects and some of the social relationships among them. Human cultures have rules for interaction among their members. People engage in a complex web of mutual obligations that change with time and circumstance. People participate in relationships, some fixed (such as biological parentage) and others temporary (such as employer-employee). Similar social relationships exist among objects, and they too must be discovered.

Note  

Another warning: We have trained users over the years to anticipate how software developers think. It is not unlikely, therefore, that they, at least initially, will try to tell you what they think you want to hear. They will couch their responses to your questions in terms of data, attributes, algorithms, and functions. When this happens, they must be questioned further to discover the behavior involved.

The metaphor of an object as a person is important for developers to begin to understand objects. It is equally useful for domain experts and should be discussed with them preliminary to any question-and-answer session. Both the developer and the domain expert can then use a common language in their discovery dialog. For example:

Well, there are customers. (User offers a potential object.)

What do you expect of a customer?

It should tell me its name, or identify itself.

What else?

It has a unique identification number.

Do you want it to tell you that number?

Yes.

Then we can say it must report or tell you its unique identification number.

Yes, and it should tell me its address, phone number, age, gender, birth date ...

Wait a second, you mean it should be able to describe itself and tell you how to contact it?

Yes, yes, exactly.

Details, and in some cases discovery, of some relationships will occur only as attention shifts to defining tests and writing code (and the implicit design that occurs simultaneously ). The domain anthropologist (embodied in the on-site customer working with technical developers) focuses on how and why objects interact and, in some cases, why they do not interact ”in other words, what rules prevent a specific object from certain types of interactions with other objects.

How objects interact is mostly a matter of recording actual and possible (desirable) conversations among objects. Why is mostly answered by seeking the task or tasks that motivated the conversation. There are different ways to organize the work required to solicit all the conversations and tasks relevant to our understanding of the domain and of the objects we might have to build to operate in that domain.

One way to organize this work ”fairly traditional in a software engineering sense ”would be to isolate a subset of the objects in the domain, draw an arbitrary boundary around them, and label the collective the NewSystem object. You could then ask each remaining object in the domain to identify the services it might require of the NewSystem object. The set of nonduplicated services constitutes the responsibilities/behaviors of NewSystem . These, in turn, will need to be examined to expose the actual multiobject conversations required to provide the identified service. Conversations might have subconversations. Eventually this process will yield a set of nested conversations, each nested thread being a use case as that concept was developed by Ivar Jacobson and incorporated into UML. Alternative, and probably better, ways to approach this work can be found by reading Alistair Cockburn s work on use cases and Larry Constantine s discussion of essential form.

Each threaded conversation can be modeled , using UML syntax, with a high-level diagram (similar to the context diagram of structured development) that represents each service consumer (user role) as a labeled stick figure and the NewSystem object as a labeled circle. (See Figure 7-2.) The making of a request by a service consumer defines a precondition for some conversation among objects within the NewSystem circle. The return of an object to the service consumer constitutes a postcondition for that same conversation. The conversation itself can be modeled with an interaction diagram. (The syntax used to construct interaction diagrams is covered in Chapter 6, Method, Process, and Models. ) Interaction diagrams can be nested, although UML graphical syntax provides no way to represent the presence or absence of a subscenario. The extended UML syntax shown in Chapter 6 does provide for branching and looping subscenario notation for the interaction diagram.

Figure 7-2: A UML-style, top-level (analogous to a context diagram) partial use case.

Note  

Use whichever syntax (graphical or textual) you prefer. Remember, object philosophy questions the utility of any representation or model beyond its immediate assistance to those involved in making the model. Don t get caught up in trying to make your model complete, accurate, or true.

This same information about the objects in a domain and their interaction can be modeled textually. The system request table (Figure 7-3) replaces the stick figure diagram of UML, and the conversation table replaces the graphical interaction diagram (Figure 7-4).

Figure 7-3: In this system request table, the service requester is identified at the top. ( NewSystem is assumed to be the service provider.) Each line identifies the service requested : the message sent to NewSystem , the object returned as a result of that request, and notes for explanations if needed. Each line of the table constitutes a precondition/postcondition for a conversation.

Figure 7-4: In this conversation table, preconditions and postconditions are noted at the top of table. Each line of the table shows who is making a request, the nature of the request (message), the service provider, the object returned, and a comment if necessary. The conversational order is assumed to be top down.

There is nothing necessarily wrong ”or non-object-thinking ”with the systematic approach just outlined. To be systematic, however, it presumes a concerted effort to identify all use cases up front and is based on defining the requirements for NewSystem . An alternative approach, one much more consistent with XP ideas and techniques, would be to define stories one object (or a small number of objects) at a time. All the same elements of discovery are present that would be in a systematic approach ”it s simply a philosophic preference to do things in the small.

We begin, this time, by looking at the semantic net constructed earlier and noting the relationship (completes) between couple and application. We then write a simple story about this relationship:

A couple requests an application for a mortgage and fills in all necessary blanks.

This story gets expanded into a sequence of interactions:

1. The couple glances at the application to make sure it is the right one (implicitly asking the application to identify itself).

2. The couple looks for the first blank spot (implicitly asking the application for the next space needed to be filled in).

3. The couple asks what information needs to be placed in that spot (implicitly asking the blank space for its label, on the assumption that the label will describe the information needed).

4. The couple enters a value in the blank spot.

5. Steps 2 through 4 are repeated (next blank spot replacing first blank spot in the description of step 2) until there are no more blank spots.

This conversation can be graphically depicted with an interaction diagram, as shown in Figure 7-5.

Figure 7-5: This interaction diagram depicts the user-driven conversation required to fill in a form.

This conversation assumes an active couple object and a passive form object. In one sense, this reflects reality: a paper form is pretty passive, and a  couple is made up of live human beings capable of action. Nevertheless, it  isn t as reflective of object thinking as it might be. Consider the alternative story card:

A couple requests an application. The application, the couple, and entryField objects collaborate to make sure every entryField needing a value contains one.

This leads to a conversation with the following steps (graphically depicted in Figure 7-6):

1. The couple requests an application from SubsidizedMortgageCompany . (Our conversation reveals a new object capable of providing an application.)

2. The application presents itself to the couple. (Implicit identity verification plus ability of the object to display itself.)

3. The application identifies the next entryField (or fields, since both a paper form and a GUI-based computer screen allow multiple entryField objects to request input simultaneously) requiring content by asking itself for the next field (or fields) and then notifies that entryField (those entryField objects) that it/they now has/have the opportunity to obtain content.

4. The entryField asks the couple for input. (Implicit request, manifested by asking a blinkingCursor to display itself in the area of the entryField or by highlighting itself in some other way.)

5. The couple provides a value.

6. The entryField notifies the application that it is satisfied.

   If it is not satisfied, an exception condition exists, and a story describing how to handle that case must be defined.

7. Steps 3 through 6 are repeated until the supply of entryField objects associated with the application is exhausted.

   
   Figure 7-6: This interaction diagram depicts the alternative scenario for filling in an application.

Differences in the conversation are minimal, but they reflect the behavioral parity of all objects ”that every object, including humans filling the role of information provider, are defined in terms of the services they can provide others. Each object is an active entity in control of its own destiny. The alternative way of thinking about the conversation also reveals objects that might not have been discovered or thought about in the original model of the conversation.

More important, the thinking behind the alternative conversational model is more general ”more abstract ”and therefore applicable regardless of the means of implementing the application. Behavioral expectations of the application and its parts are consistent whether implemented with paper or as a software application. True, the software versions of the objects have more interesting or dynamic ways of exhibiting behavior. An example is the entryField object using the services of a blinkingCursor instead of simply displaying itself as a blank space.

The alternative model is also more consistent with user expectations of the objects involved, which is the real goal of domain anthropology. If we are to build digital versions of forms and entry fields, they should reflect the expectations of their naturally occurring counterparts. For example:

• We expect application forms (any form, for that matter) to present their constituent parts (labels and entry fields) to us in an organized and reasonably clustered way. In the digital manifestation of the form, this is accomplished through interaction with a cursor or, more crudely, by presenting the entry fields to the user one at a time. In the paper implementation, the form still presents the elements to us in order but does so implicitly ”taking advantage of cultural conventions. ^[2]

• We expect entry fields to ask us to enter a value. The digital version does so by using a blinking cursor assistant object to remind us that it is waiting and refusing to go away until it is satisfied. The paper version does so by nagging us simply by remaining blank. Nature abhors a vacuum no less than a human abhors a blank spot on a form.

The value of applying object thinking to conversation discovery and modeling will become more evident as we consider responsibility assignment and discovery in more detail. Here s a preview: allowing entryField objects and form objects to validate themselves in collaboration with another object (a rule object). A paper-based entry field seeks validation by displaying its content to a human and asking for confirmation or replacement of its displayed contents. A digital version could do the same thing by asking a rule or rules to evaluate themselves (to true or false) using the value held by the entry field as one of the rule variables .

A reader note earlier in this chapter suggested that a domain anthropologist brings to bear a certain sensitivity or objectivity by virtue of being an outsider. Seeing the implicit behavior of forms and entry fields, just noted in immediately preceding paragraphs, is an example of applying this kind of objectivity. It would not occur to a typical user to volunteer how they interact with forms and entry fields because that interaction is based on cultural conventions that are nonconsciously applied. The conventions are nevertheless real and need to be identified and exploited in order to develop and design the most robust objects and applications.

^[2] Reflects U.S. and Western culture. Other cultures use right-to-left and down before left-to-right conventions.