How to design your CorDapp’s business logic using the ‘five questions’ method

CorDapp (Corda Distributed Application) is a distributed application that runs on the Corda platform. It contains states, contracts, flows, and services.

I’m an intern at R3 and have recently written a CorDapp from scratch, which is a concert ticket booking application. The reason why I choose the Corda platform is that in Corda’s network, the identity of each joiner needs to be checked and proved by the network organizer. Unlike other DLT platforms that broadcast transactions, Corda completes transactions in a more private way. I think this is an interesting experience to share and I believe what I learned could be useful for anybody else starting out on their Corda journey!

I have divided the content into the following six sections:

• Design the business logic
• Build CorDapp
• Build RPC
• Build front-end pages
• Additions
• Problem shooting

This blog is mainly about designing the business logic, which is the most important step in my opinion. Because a reasonable business logic makes your CorDapp meaningful. I will introduce the ‘five questions’ method I applied to design my CorDapp’s business logic.

The ‘five questions’ method is about asking yourself the following 5 questions:

1. What’s the general procedure in reality?
2. Who will participate?
3. What items are included?
4. What are the steps?
5. What’s the order of these steps?

Let’s take a deep dive into these 5 questions!

1. What’s the general procedure in reality？

Imagine this: Justin Bieber has just announced on Twitter that he will perform in London in December 2022. If customers are interested in attending, they will need to visit the booking site and retrieve information for that concert. They will then need to fill in the purchase information form. This form has performing act details, venue details, the customer’s personal information, and payment details. After completing that, they click on the payment button. A few days later, the ticket they’ve ordered have been shipped. On the day of the concert, they will take that ticket to the concert with much excitement, letting the venue staff check your tickets. Finally, they will see the idol!

2. Who will participate?

There are at least 3 participants in this use case — website holder(we just assume it’s the one who receives money for the booking), ticket buyers(us in this case), and venue holder(who validates the ticket and let us in). Anyone else?

Think about where is the money coming from?

Money is always issued by a bank. So the bank is involved in the whole process.

In this CorDapp, there are four participants: Bank, who issues money. Buyer, who buys tickets like us. Agency, who receives money for the booking. VenueHolder, who redeems the ticket.

3. What items are included?

There’s no doubt that money and ticket are included in this procedure. And don’t forget the purchase information form customers filled in! It’s that form that tells the agency which concert they would like to book.

You might think: Why the VenueHolder is happy to let customers in even though they don’t pay them directly?

The answer is that there is an agreement between the VenueHolder and the Agency that permits the Agency to use the venue and make a profit. Let’s call it venue ownership in this case. The venue ownership defines who will use which concert hall for how long.

We can conclude there are four items included in this process — Money, Ticket, VenueOwnership, and Request(a.k.a. purchase information form).

4. What are the steps?

Steps tell us about the relationship between participants and items. We’ve already defined four participants: Bank, Buyer, Agency, VenueHolder, and also we have four items: Money, Ticket, VenueOwnership, and Request.

The primary responsibility of the Bank is to issue Money.

For the Buyer, it sends the Request, pays the Money, and gets the Ticket.

The Agency needs to take on three main tasks:

1. Pays Money to get the VenueOwnership
2. Reviews the Request and decides whether to accept it or not
3. Gains Money from selling Tickets

For the VenueHolder, it gains Money from selling the VenueOwnership and is in charge of redeeming the Ticket.

One thing to note here, according to Corda’s business logic, the one who redeems the state should be the one who issues it.

Therefore, the VenueHolder is the one who needs to issue Tickets. The finalized steps are shown in the following figure.

What’s the order of these steps?

Firstly, the Bank issues money to the Agency and the Buyer. Next, the VenueHolder sells the ownership of the concert hall to the Agency and gets paid. The Buyer then generates a ticket request, the Agency reviews it, decides whether to accept or not and gets paid. Finally, the Agency updates the request information to the VenueHolder and the VenueHolder is in charge of issuing the concert ticket to the Buyer. The following chart might be helpful for your understanding.

You may find those answers are exactly the basic composition of this concert ticket booking Cordapp. The participants refer to Corda’s Nodes, the included items refer to Corda’s States and each step corresponds to a workflow in Corda. I hope this ‘five questions’ method could help you sort out your logic for your own design!