Page 33 - MSDN Magazine, September 2018

Figure 1 Microservices and Blockchain Design Principles
Another benefit is better runtime scalability, which allows a software system to grow or shrink with demand. Smart contracts implemented as microservices enable permissioned blockchains in a private business or consortium environment to distribute workloads for transaction and mining nodes in a more flexible way.
At its most basic level, microservice architecture is about break- ing up an application or system into smaller parts and gaining benefit from the distributed setup. In the same vein, smart contracts that run on a blockchain benefit from the distributed nature of the peer-to-peer network. With a microservice architecture-oriented design, smart contracts can deliver improved efficiency, scalability and manageability—all attributes that are essential for proper im- plementation of blockchain solutions in the enterprise.
Decentralized Domain-Driven Design
Write an application for a decentralized blockchain digital ledger and you’re working with infrastructure and software requirements typical of a distributed system, such as storage isolation, asynchro- nous messaging and distributed transactions. Blockchain applications also require authentication of users and devices, and authorization to execute specific actions within a smart contract. Expanding on the popular Domain-Driven Design (DDD) approach, I refer to the practice of considering entities, processes and properties of a block- chain system as “Decentralized Domain-Driven Design,” or DDDD.
Let’s start defining the domain, or context, of the execution of smart contracts within a digital ledger. Smart contracts represent the business logic of the blockchain application as workflows, with each stage of a workflow identified by a message sender (a user or device that executes a function of the contract) and a state (the parameters of the contract, represented as a message sent to a func- tion, and its internal status). Other parties (again, users or devices) may be affected by the execution of a function of a smart contract.
Each contract contains roles, state and functions to implement actors, stages and actions of a business process.
In this context, we refer to all parties involved as application roles. The very first application role that creates the contract is called the initiator. On change of internal state of a contract, an event may be raised to signal this change to other parts of the smart contract, or to external applications. This is a typical pattern, for example, for populating off-chain data, by using a service bus for processing
events raised by a smart contract and pub- lishing messages to the relevant listeners. Figure 2 identifies the entities involved in a workflow within a smart contract.
Ethereum uses Solidity as its program- ming language for writing self-enforcing business logic for smart contracts. Smart
September 2018 25
Design Principle
Microservice
Smart Contract
Single responsibility
Typically provides a CRUD interface on a single entity.
Defines roles, state and the relevant logic for a validation workflow on a single object, using the CRAB approach (more later in this article).
Context bounded
No dependency on other services, owns its data model for persistent storage.
Does not have dependency on other smart contracts and leverages the on-chain data model (that is, the blockchain itself) as the preferred data model.
Messaging enabled
Can leverage an API gateway for inter-service communication, and
a service bus for intra- service communication.
Can leverage “oracles” or “cryptlets” for off-chain data access, or tools
like Azure Blockchain Workbench that expose a REST API.
Autonomously developed
Multiple programming languages and frameworks.
Multiple blockchain platforms available, although no cross- platform communication currently exists.
Independently deployable
With proper design (event sourcing, CQRS) can reduce or remove dependency completely.
Similar design patterns apply (described in this article).
Distributed and decentralized
Distributed architecture as opposed to a centralized “monolith.”
Built-in distributed and decentralized digital ledger by design.
Designing blockchain applications with microservice architec- ture principles can also yield business benefits. Improved efficiency in the software system reduces infrastructure costs and the risk of capacity-related service outages. These aspects are of particular value to private blockchains, where cost effectiveness and service continuity are key requirements for businesses.
Microservice architecture principals can support use of replace- able components, reducing technical debt that can lead to aging, unreliable environments. Solidity, the programming language for smart contracts in Ethereum, has a mechanism for specifying the exact runtime version on which each contract is executed. Over time, a smart contract’s version number can be used to identify obsolete blockchain-stored code that may be a candidate for replacement. Just keep in mind that in a blockchain, smart con- tracts that have already been processed (that is, are part of a “mined” block) cannot be deleted—a new version of a contract must be published for future transactions.
Figure 2 Workflow Entities in a Smart Contract msdnmagazine.com
Workflow
Won Amount Execute Function Change State Raise Event