In the sample code at 09-module-patterns/09-aggregator-and-facade-modules, the module pattern.nine.facade acts as an aggregator and facade module that consolidates two separate modules--module.one and module.two. It has a transitive dependency on both those modules, so any module that reads pattern.nine.facade also automatically reads those two modules:

    module pattern.nine.facade { 
      requires transitive module.one; 
      requires transitive module.two; 
      exports pattern.nine.external; 
    } 

Not only does the module do that, it also has a thin facade API. There's a class it exports--FacadeApi that has an example method to illustrate how a method can choose between two implementations. Here, the method chooses one of two implementations based on an input String value. But you can easily imagine facade APIs written in such a module that offer help around business rules or logic of your application that affects which libraries are used:

    public void facadeMethod(String apiChoice) { 
      if ("one".equals(apiChoice)) { 
        apiOne.apiMethod(); 
      } 
      else if ("two".equals(apiChoice)) { 
        apiTwo.apiMethod(); 
      } 
    } 

Now, the consumer module that reads pattern.nine.facade has two options. It can either access the library modules directly (And it can because of the transitive dependencies--it transitively reads both module.one and module.two). Or, it can call the API through the facade method to get help on which one to call. Both work perfectly fine, as you can see in the following code:

    public static void main(String[] args) { 
      FacadeApi facade = new FacadeApi(); 
      ApiTwo apiTwo = new ApiTwo(); 
      facade.facadeMethod("one"); // Calling the API through the facade 
      apiTwo.apiMethod(); // Calling the other API directly 
    }