Hello,
is it possible to do Domain Driven Design in UiPath?
In some computer languages such as Java, you can create layered architectures, with, say, a Presentation Layer, a Business Logic Layer and a Data Access Layer (cf. Learning Domain Driven Design Book).
Can you do the same in UiPath?
Many thanks
To a degree, yes.
What layers do you currently see?
Thanks for replying.
It the UiPath applications I’ve seen so far, the three layers where all mashed up. For instance, DataTables were filled with hodge-podge (eg. client id, amount spent, ..) data retrieved via SQL.
There is for sure some terribly messy data variables with datatables etc in some sloppy solutions. But just curious to know what part you most think needs to be abstracted into a different layer.
You think a data layer is needed in those projects or?
Exactly.
This book recommends separating Data Retrieval from Business Logic from Data Presentation.
Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy: Khononov, Vlad: 9781098100131: Amazon.com: Books
I personally believe that using DataTables as do-all objects is a mistake (but I’m neither an UiPath nor a DDD expert).
A colleague of mine mentioned the RE Framework.
Yes, I know, but designing an app is very different cause you usually have different requirements for data storage / persistence and there isnt a presentation layer unless you build an app, which is a totally different thing.
In an automation there is no ‘presentation layer’ as you arent building a Ui.
The REFramework is not a domain layer but a framework for transactional processing.
This is why I ask what layers you perceive the need from or if you are trying to ‘fit a square peg into a round hole’ and just trying to use terminology without being sure how / where to apply it?
agreed to:
we should also see that they coming from another side and do have another control of solution design control
we can design our XAMLs and also can separate it into the layers
Presentation - Ui-Interaction
Logic - Decisions, Data Evaluations…
Data Access - DB Queries, API Calls, Integration Service
But compared to programming languages, we differ in the technical possibilities, such as implementing a business domain model with its derived business classes using XAMLs.
When retrieving data from UI (e.g. Table Data Extraction) our Data Source is not a Datatable but the UI. So just to mention an example that shows us that we also have to adapt concepts to the RPA World.
Lets elaborate more on the statement:
we can design our XAMLs and also can separate it into the layers
Mission:
- extract Data
- evaluate Data and compute its Flow Logic rule outcomes
- click in Ui on the related uiElements (e.g a OK Button, a Cancel Button)..
Separated XAMLs:
- a forefront caller XAML offering the Functionality of taking out a car from the car pool
- RetrieveCarPoolData.xaml
- FindCarByCriterias.xaml
- TakoutCarFromPool.xaml
vs.
a single XAML e.g. modelling all steps in one
Also lets keep in mind:
- a few sentences will not be enough to elaborate all in depths
- in RPA implementations we also compromise and balance other factors like
- skill set of users, doing the implementation
- given technical capabilities (Studio, Studio Web, Studio X, Workflow Foundation…)
- Project Coding Guidelines
- … and others
Nice to see you here Peter,
I am hoping, with the new capabilities with the Agentic Orchestration layer that having an Orchestration layer, which could also be called the business logic layer, will become alot more mainstream, with performers dedicated to Ui tasks only and so perhaps being considered the ‘Ui layer’.
From my understanding of separation in the world of front end design, a ‘Data layer’ per say doesnt quite match up properly as alot of the time the data isnt persistent enough to warrant such a architecture and it can mostly be handled in the Orchestration layer.
I think Libraries also play a part, but are perhaps not clear as a layer, but this is where I like to define all the actual Ui interactions, with them being wrapped into re-usable activities which can then be leveraged in a performer.
Its largely a semantic choice, and the ‘layers’ should not conform to the same standards as in front end design, your notes on simply splitting workflows into layers could be considered to be simply following SOLID principles, but they could be also argued as a type of ‘workflow layers’ whilst I was thinking more in terms of projects.
Let’s assume a project handling Purchase Orders.
Some Order data would be retrieved as Excel workbooks from Source 1, further to an RPA Robot having filled out a form on the Source 1 Website. Other Order data would be retrieved from other sources. The generated Excel files would then be aggregated, and “filtered” (to eliminate rows that don’t meet certain criteria, e.g. Amount < 10 euros).
In OOP, the Data Layer would deal with the data retrieval and aggregation. The Business Layer, would, i assume, deal with data filtering.
How can you create such layers in UiPath?
Gentlemen (and ladies),
maybe the solution lies in using a mix of OO (and perhaps functional) VB or C# to create Entities, Interfaces and Services, and UiPath code to handle the UI and data retrieval. What do you think? The book I’ve mentioned above provides examples of such Entities, Interfaces et al.
Like I gave examples of before.
You have an orchestration layer, which is where all the business logic is and can handle the data that stays relevant for the business process. However you don’t make a dedicated data layer for everything because we aren’t making a single app here. Again why applying the exact same design patterns dont make sense.
Lets take an Orchestration model, its triggered to start off the process.
The first step is reading an Excel file, now if thats a file on Sharepoint it can just do it directly, but you can of course just make a workflow dedicated to it that handles and filtering or whatever to it. This abstracts the task away and makes it way easier, in the future, to swap that component to be reading from say a SQL server instead.
You don’t however make a data layer that connects all the data between these two processes (the orchestration and the Excel Reading process) because there is no benefit to that any more than you need a data layer that connects all the different applications you use. They are different participants.
To illustrate this further. Later in your process you might have the task to fill in information into Website 1. The orchestration would not be responsible for completing this, task in the website. It delegates that work to a ‘performer’ layer which is a robot built in the REFramework. This wont share the same data layer as the Orchestration though as a performer might be connected to several different business processes, all separated, and act as a microservice.
If you operate in that mindset, of robots working as microservices that are co-ordinated on a different layer, the data layer becomes something that would be confusing an un-needed.
I feel I’ve explained this in not the most ideal way, cause we are talking about alot of abstract concepts. But my wider point is its for sure a great idea to separate things into different layers on a conceptual level, but that trying to directly apply the concepts from Front End programming in Java is not smart in my opinion.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.