The three scenarios from listing 2 are focused. They talk about one thing and one thing only-the topic of security (see table 1). Their business context explains that. They were created when Activitee signed a new client who had an active Chief Information Officer responsible for the information technology and computer systems used in their company.

Table 1. Domains in listing 2

Specifications like this are easy to analyze, because they're unequivocal. We can derive the domain easily as the scenarios only talk about a single topic. If all Gherkin specifications maintained this one-to-one relationship between scenarios and domains, our job in this section would almost be done. Unfortunately, as we saw in figure 2 and as we'll see in the paragraphs to come, reality isn't always organized this neatly.

Distilling subdomains from mixed scenarios

Here are some specifications that allow HR representatives to target their programs to specific audiences to allow engineers to see different events than sales representatives, as their interests may differ (see listing 3).

  
 Ability: HR reps can target wellness programs by choosing specific audiences
  
   Scenario: Managing participants based on selected people
  
     Given Mike drafted a new event
       And he chose to invite only selected participants
      When he invites Simona for an annual review
      Then only Simona should be notified
       But other employees such as Jane should not be notified
  
   Scenario: Managing participants based on their location
  
     Given Mike drafted a new event
       And he chose to invite only selected participants
      When he invites employees from Atlanta
      Then employees in all departments from Atlanta should be notified
       But employees from New York should not be notified
  
   Scenario: Managing participants based on their department
  
     Given Mike drafted a new event
       And he chose to invite only selected participants
      When he invites employees from Engineering
      Then employees in all locations who work in Engineering should be notified
       But employees who work in Sales should not be notified
  
   Scenario: Managing participants based on their location and department
  
     Given Mike drafted a new event
       And he chose to invite only selected participants
      When he invites the Engineering team from Atlanta
      Then employees in the Engineering team in Atlanta should be notified
       But employees who work in Engineering in New York should not be notified
       And employees who work in Sales in Atlanta should not be notified
       And employees who work in Sales in New York should not be notified
  

Table 2. Domains in listing 3

The language in the four scenarios from listing 3 isn't as unequivocal as in the previous specification we analyzed (see table 2). At least two domains can be derived from our new steps. Some domain concepts refer to the events domain, and others to the domain of organization.

If we only wanted to analyze the ubiquitous language of our specification suite, saying there are two distinct domains at play here would be fine. The problem is that we want something different. We want to organize the suite by its domains. As the file system is a hierarchic structure, we'll only be able to assign the feature file including the Ability from listing 3 to a single domain (if we want various directories to represent various domains). Therefore we must choose between the two domains we've distilled.

We can make our choice based on multiple approaches:

• we can treat the core domain as more important than other subdomains

  • in Activitee's case the events domain is clearly the core domain

  • the downside of this approach is that the core domain would always take precedence in every scenario it appears in-which isn't something we'd want, as most scenarios must deal with the core domain in some way or another

• we can count the domain concepts (words) in each domain and assume that the more popular domain is also more important

  • the first downside is that we've no guidelines for dealing with draws

  • the second downside is that some domains will be more popular only because they're more generic than others or because they've more non-functional aspects, making it easier for them to spread horizontally across the suite

• we can combine the two previous approaches to "calculate" relative weight of each domain

  • this way, we acknowledge that some domains (such as the core domain) are inherently more important than others

  • but we also acknowledge that domains with more domain concepts present can, in some cases, be more essential than even the core domain

Table 2 shows that the specification from listing 3 is close to a draw, with a 5-4 result. We can assume that both distilled domains are almost equally important to our distillate. Personally, I'd recommend choosing the events domain because the scenarios talk only about managing participants and the core domain can take precedence in this case. Let's talk about an example when the opposite would be true. This specification says that employees should only see Activitee content which is relevant to them-and that the relevancy should be calculated based on their branches and departments (see listing 4).

  
 Ability: Employees can see content they like in the news feeds for their branches
  
   Scenario Outline: Employees should only see content relevant to them
  
     Given  from  who works in 
      When  looks at the company dashboard on Activitee
      Then  should see  
  
     Examples: Employees should see after-work content only from their location
       | person | branch | department | type | content |
       | Jane | New York | Engineering | New York after-work | events |
       | Mike | New York | HR | New York after-work | posts |
       | Tom | Atlanta | Sales | Atlanta after-work | events |
       | Ramona | Atlanta | Engineering | Atlanta after-work | posts |
  
     Examples: Employees should see work-related content from all locations
       | person | branch | department | type | content |
       | Mike | New York | HR | Atlanta HR | events |
       | Jane | New York | Engineering | Atlanta engineering | posts |
       | Jane | New York | Engineering | New York engineering | events |
       | Tom | Atlanta | Sales | Atlanta sales | events |
       | Ramona | Atlanta | Engineering | Atlanta engineering | posts |
       | Ramona | Atlanta | Engineering | New York engineering | events |
  

Table 3. Domains in listing 4

If we have a look at table 3, we'll see that listing 4 is the opposite of listing 3. We're close to a draw again-but this time, it's a 4-5 result in favor of the organization subdomain. This, and the fact that the examples talk not only about events, but also posts in interest groups, encourages me to recommend adding this specification to the organization subdomain. Here's how that might look:

Figure 3. how the domains organize the files in the specification suite

That's all for this article. Hopefully this has been a thought-provoking read on deriving business domains from ubiquitous language.

If you want to learn more about the book, check it out on liveBook here and see this Slideshare presentation.