Skip to content

Design Principles and Patterns

Ranjan Dailata edited this page Dec 17, 2019 · 1 revision

Here's you will see the details about the well-known design patterns and principles implemented in the SaleDeedRegistry solution.

  1. Domain Driven Design (DDD) - The Sale Deed Registry functionalities are coded with the DDD in mind. We have created necessary domain entities that will help in fulfilling the Sale Deed handling with ease. The DDD allows one to easily enhance or extend the solution.

  2. SOLID principles - The SaleDeedRegistry solution is coded with the SOLID principles in mind. The libraries and applications are coded with the SOLID principles to take advantage of the code readability, easy to extend and fix issues.

  3. Facade Pattern - We have a Sale Deed Facade responsible for handling or executing the SaleDeedRegistry contract operations. Internally, it's making use of the Stratis Contract Swagger API. The Facade simplifies or hides the contract calls. In addition it also deals with the Stratis Receipt API calls and hides all the complexities of dealing with the subsystem interaction. The Facade lets the consumers to easily interact with the SaleDeedRegistry contract. It also helps the developers to extend the solution with ease.

  4. Command Pattern - The Command Pattern is being implemented for interacting with the SaleDeedRegistry Smart Contract. The contract is driven by the State and hence the command pattern suits them best in performing the contract actions. Basically, we are encapsulating the Sale Deed Request object and then executing it to perform a specific operation based on a given state.

Clone this wiki locally