We now know how to create demo data in the database using the persistence and business layer. Now we can start laying the foundation for developing an architecture that allows us to model business objects and processes. There are two ways we can go about this:
- We generate an entity for every object, based on the attributes of the object. Likewise, depending on the future processes that object will be involved in, we can model these processes individually for each object in an optimised way.
- Alternatively, we can develop a framework that allows us to continuously generate new object types with custom attributes and customisable process flows.
Both strategies have their pros and cons. For a large system, the first approach has an edge since it allows optimising the architecture for performance and stability. The second one will inherently involve a higher degree of normalisation, which reduces the development efforts but increases the demand for the hardware infrastructure and QA/ testing.
For this project, we have very limited development resources while testing can be automated, and hardware is comparatively cheap and tends to get cheaper over time. We will therefore opt for option two, developing a generic system with a higher possible degree of customisation.
Modelling business processes
Our trading platform will have 2 types of processes that will affect objects.
The first type includes any modifications of master or object data, like creating a new object or changing a property of an object. These processes are usually fairly simple, with the only complexities usually arising from cases like 4 eyes checks or when waiting for input from a client or a third-party system.
The second type of processes are those, that generate a transaction with bookings. Bookings are events that change the value of a position. A typical example of a process that triggers a booking is the sale of a Share, wherein a stock position is debited, and a currency position is credited.
Let us look at a simple master data process flow, that is, a process that modifies an object. Following the general idea of BPMN, we have a start state and an end state. In between, we have states (here: “open” and “hold”) and actions like “Modify”, “Open”, “Store” and so on. For the sake of completeness, the depicted chart visualises where the data gets stored in the process flow.
Process flows for transaction data can often be more complex. Eventually however, the basic concepts of states, and actions will remain the same. That is important, because it implies that we can use the same implementation for both types. We will just need to add properties that define what kind of process we are dealing with, like master data or transaction data, and what business type is affected, e.g. asset, person, country, payment, stock exchange order.
We already know that to model the world, we need Objects to represent entities of the real world. To model the process of modifying these objects, we need an additional entity. As described above, the processes that we will model with that additional entity will be very similar to those of typical business transactions like Payments or Stock purchases. In business, the common term for that entity is Order. A typical example would be a payment order, a stock exchange order or even an order to your bank, for an update of your personal address after you moved to a new house.
As depicted in the image above, our world will therefore consist of two basic elements: Objects to model entities of the real world and Orders, enabling us to implement business processes. Orders will be either transactional, triggering bookings or they can be master data orders, triggering CRUD operations on Objects.
Due to the basic nature of these entities, the Java classes for them will be equally simple, containing just the most basic information about their identity, business type as well as time of creation and last modification.
An order will moreover reflect if it is a master data order or a transaction order. To keep track of the system security, it will also store the user who initiated the order. As described previously, an order represents the entity that moves through a process flow to fulfil a task. As such, it will always be in a certain state. We call that state “prcStatus”. We will learn more about the order status once we discuss the implementation of the process flow in our system.
Objects will also have fields giving us additional information about their state. A reference to the order that created the object will lead us also to the user who triggered the creation. And with the field “orderMdf” we will be able to check if this object is currently in work by another order and if so, which order that is. That helps us keeping our data consistent while also giving us a way to find out, who is currently blocking the object we would like to modify.
For now, that concludes our examination of objects and processes. In the next article, we will explore how we can use objects and orders to model workflows and which additional entities we will need for that implementation.