We now move to the next set of definitions in the model file: the participants!

Let's have a look at the first participant definition:

participant Bank identified by bankID {
  o String bankID
  o String name
}

This is our first participant type definition, a bank. In the sample application, we have two instances of this type: Dinero Bank and Eastwood Bank.

We can see that participants are identified by the participant keyword, after which follows the type name–Bank. In this case, a participant type is an organization, rather than an individual. As with assets, every participant has a unique ID for identification, and we can see that for banks, it's the bankID field:

participant Bank identified by bankID

For our example, a bank has been modeled very simply–just a bankID and a name, both of which are strings:

String bankID
String name

We can see that banks really are much simpler than letters. It's not just that they have fewer fields with simpler types. More importantly, they don't refer to any other participants or assets–that's what makes them simple–a lack of references, a simple structure. Your models will be like this too–some assets and participants will have a relatively simple structure, whereas others will have much more, including references to other assets and participants.

Recall that these types were referred to from the asset definition. If you need to do so, look at the letter type definition again to see the references:

--> Bank issuingBank
--> Bank exportingBank

Can you see how the letter asset and bank participants are related now? Great!

Let's now look at the next type of participant. It's a little different to what we've seen before, and for now, ignore the abstract keyword:

abstract participant Person identified by personId {
  o String personId
  o String name
  o String lastName optional
  --> Bank bank
}

It feels like we have four instances of the Person type in our application–Alice and Bob, Matias and Ella! Let's have a look at how individual participants are defined:

abstract participant Person identified by personId

Again, ignore the abstract keyword. This statement defines the participant of the Person type that is identified by a unique field in its type definition. These types are going to be the individual participants in our application, rather than the organizations (that is, banks) that we defined earlier. (We might expect that Bank and Person will be structurally related–we'll see later!)

If we look at the definition in a little more detail, we can see their structure is a little more interesting than bank:

o String personId
o String name
o String lastName optional
--> Bank bank

We can see that Person also has a name and a last name. But notice that the last name is optional:

o String lastName optional

We can see that the optional keyword indicates that lastName may or not be present. You may recall in our example that Alice and Bob provided surnames (Hamilton and Appleton), but the banks' employees, Matias and Ella, did not. This optionality has been modeled–see how it helps us make our applications more like the real-world.

However, the most important field is the next one:

 --> Bank bank

Why? It reveals structure. We can see that a person is related to a bank. In the case of Alice and Bob, it's the bank they have accounts with. In the case of Matias and Bob, it's their employer. We'll come back to whether this is actually the right place to model this relationship, but for the moment, what's important is that we have an individual participant that has a relationship with an organizational participant. You can see that it's not just assets that have complex structure–participants can have them too!

But hold on, it's not quite that simple. We skipped something in the definition, didn't we? See the following:

abstract participant Person identified by personId { 

The abstract keyword almost totally destroys everything we've just said about Person types! The abstract types are special because they cannot have instances. Really? That's seems counter-intuitive, given we can see Alice and Bob, and Matias and Ella. 

To understand what's happening, we need to move to the next participant definition:

participant Customer extends Person {
   o String companyName
}

Look carefully at the first line of this definition:

participant Customer extends Person {

 We can see that we've defined a special type of Person called a Customer! That's better than before, because Alice and Bob are Customers. We don't actually have instances of Person participants in our application–we have instances of Customer types.

We can see now that the extends keyword in the Customer type definition is paired with the abstract keyword in the Person type definition. They are part of this bigger idea of the type specialization and inheritance that we referred to earlier:

abstract participant Person
participant Customer extends Person 

It's the abstract keyword that stops us defining instances of Person! That's important, because in our example, it's actually correct–there are no instances of the Person type, only instances of the Customer type.

We can see that a Customer has one extra attribute when extending a Person type, their company name:

o String companyName

In the case of Alice, this will be QuickFix IT, and for Bob, it will be Conga Computers.

Finally, let's look at the last participant type, BankEmployee:

participant BankEmployee extends Person {
}

We don't need to describe this in detail–you can see that, such as Customer, BankEmployee extends the Person type, but unlike it, it does not add any extra attributes. That's OK! In our application, Matias and Ella are instances of this type.

We can now see why the Person type is helpful. It's not just that it cannot be instantiated, it's also that it captures what's common between Customer and BankEmployee. It doesn't just save typing–it reveals an inner structure that improves and reflects our understanding of the business network.

Bearing this in mind, you might like to consider whether it might be slightly more realistic to model as follows:

abstract participant Person identified by personId {
   o String personId
   o String name
   o String lastName optional
}
 
participant Customer extends Person {
   o String companyName
   --> Bank customerBank
}
 
participant BankEmployee extends Person {
   --> Bank employeeBank
}

Can you see how this model shows that the nature of the bank relationship is different for Customer than it is for BankEmployee?

There's an important point here–there is no such thing as a correct model. Models merely serve a purpose–they are either sufficient or insufficient. Both of our models are perfectly sufficient for our purposes because we don't need to make a distinction between Customers and BankEmployees in terms of their relationship to a bank.

OK, that's enough on participants. Let's move on to the next element in the model definition.