A core tenant of the DAS approach is that the latest version of all of the data is held in the DAS – Data at Rest (DAS-DR) service. For record data, this means the DAS-RSS.
Since all interactions with data are mediated through the DAS-DR, the implementation of any action can immediately access any data without going through a series of hoops. This essentially flattens a traditional micro-service architecture where you might have to navigate through a series of Customer, Order, Fulfilment, Pick, Pack, Ship services to collect information required to process an Order. You don’t need eventual consistency, caching, or other common micro-service anti-patterns.
Actions can be implemented and deployed as fine-grained loosely coupled components. In the limiting case, each action can be deployed as a separate component. For example, if you need to process two types of Order, you can deploy two separate services. If you need to update, or replace one, it won’t affect the other.
The only “limitation” for the implementation of an action is that it must be able to connect to the DAS-DR. The means that you are free to use whatever technology and deployment pattern you chose, including:
- Open API – Actions as implemented as API endpoints
- T-SQL Stored Procedures – Action are implemented in the database using stored procedures.
- Windows Services – Actions are implemented as operating system services that constantly run in the background.
Actions can be:
- Invoked by the user through the application user experience
- Run as background, or polled services
- Initiated by events, or schedulers
Actions are executed in the context of a secure user session authenticated with a SessionGUID/UserGUID matching pair of parameters. The valid combinations of SessionGUID/UserGUID are held within the DAS-DR for validation purposes.
Actions will also be passed a Current Instance GUID and an optional Target Instance GUID. The Current Instance GUID specifies the record that will be acted on and the Target Instance GUID identifies an optional second record that contains additional information required to complete the action on the current instance.
An action may place a “lock” on the current instance to prevent multiple concurrent updates to the instance.
The implementation of action follows the same generic pattern:
- Read the required data from the DAS-DR (validating that the user has access to the required data), or from any required external data source(s)
- Perform any required processing or transformation of the data
- Write the results back to the DAS-DR
The action components should retain no data, or state, making them horizontally scalable.
Where practical, actions should be completely self-contained and not coupled to other actions. Each action has direct access to all required data and should not need to call upon other actions to complete processing. Any code common to more than one action should be contained in its own shared library with its own CI/CD pipeline and automated testing.
Generic trellispark Services
trellispark includes a set of generic services for the following functions:
- Processing trellispark Messages Using a Windows Service
- Updating the Automated Messaging Process List Using a Windows Service
- Performing Scheduled Tasks Using a Windows Service
- Processing Queued Commands Using a Windows Service
Guidelines for building actions
- Push the processing as close to the data as possible. The first choice would be T-SQL Stored Procedures in the database to maximize performance.
- Keep the action hierarchy as flat as possible – use shared code libraries instead of having actions call actions.
- Create re-usable actions that can be configured using data.
- Place as much logic into re-usable class libraries as possible.
- This article describes how to create a new Windows Service for trellispark
Sustainability Considerations
- Minimise the number of technologies in use
- Standardize how each technology is used and share best practice
- Update architecture as better technologies become available
- Design reusable components that can be easily configured using data
- Maintain a consistent interface so that services can be easily composed
- Keep configurable units small to make them easy to version and deploy
- Use automated tests to maintain quality
- Use automated CI/CD pipeline tools
- Uses a smaller infrastructure footprint
