In this presentation, we introduce the software platform, Dbquity [9], and some learning points about REA models. Dbquity lets you declaratively model data structure and express derived information at the domain expert's level of abstraction without over-specifying or repeating knowledge using a dedicated declarative1 language, which centers on the notions of entity and association and single inheritance with powerful member-specialization capabilities, and lets you work on multiple levels of abstraction factoring out domain-specific, reusable libraries. The language abstracts away all implementation details, and the model declared is executed directly by the Dbquity runtime without any need for further artefacts. Design goals for Dbquity include, that based on a single inheritance combined with expressive, intuitive constraints, the language must support both basic and more advanced REA patterns such as policy and valuation whilst aiming to be if not writable, then at least readable for non-programmers using a no/low-code approach. Further, the system must be able to generate the required set of reports from the model itself in as simple a way as possible. We aim to open source the specification of the language itself and keep the core tooling and runtime implementations closed source. The first2 incarnation of the runtime targets a simple, ubiquitous twotier topology using cloud-based storage and mobile phones aiming to make it as effortless as possible for modelers to distribute Dbquity models and for consumers to use the models. Our work includes several examples to make it clear how to implement REA patterns using Dbquity, and we hope to get feedback on the presented models, the language, the tooling, and the current scope.
1.1
The Dbquity language introduced by an example The example of (a sketch of) a REA library and a DAAS design referencing that library in figure 1 on the following two pages shows how the Dbquity language uses semantic indention such that text indented under a model element is either properties of that model element or nested elements or members of that same model element, meaning that the Agent entity will have a field of type text called Name and the identity of the Agent will be the Name.
In general, a type followed by a name declares an element or a member of that type, and properties are declared by their name followed by a colon and the property value, which is often an expression over the model.
Dbquity stores data in a hierarchy of entities rooted by areas. An area is itself a (special kind of) entity. Only concrete (not abstract) entities declared inside an area will be instantiable at runtime.
Note how the name of a previously declared entity can be used as a keyword for declaring a specialized entity. For example, the line Agent Producer, declares the Producer entity in the Sales area specializing the Agent entity of the REA library.
library REA entity Resource text Name identity: Name decimal Price entity Event date When decimal Amount entity Agent text Name identity: Name design DaaS references: REA area Sales
decimal ComputerPurchaseTotal
expression: Lessor@Sale.sum(Amount) integer ComputersBorrowed
expression: Lessor@ComputerBorrowSale.count(Active)
link User
expression: Computer@ComputerBorrowSale.last(Active).User link Soldto entity: User expression: Computer@ComputerBorrowSale.last(Sold).User
link Producer link Lessor link TransportService link Computer Listing 1: Example of a Dbquity design referencing a library (continues on next page) Listing 1: Example of a Dbquity design referencing a library (continued from previous page)