we are about to embrace TM5 and the Fluent SDK, so I'm keen to make a good start and use best practices.
So, I was wondering about how best to structure my IDE projects - we are using IntelliJ IDEA.
I was planning to set up each service as a single project, rather than have multiple services in a project.
I'm wondering if this has any impact on deployment or development activities. Is there a recommend way to structure this, or is it a matter of me adopting my own best practices. Any feedback would be welcome.
Good question Mark, and great to hear that you are charging forth on the Fluent SDK!
My advice would be to keep all related services in the same project. That is, all services related to the same task/function/capability (from a user's perspective) should be kept together. Think of the app-store concept where each app is a project that adds capabilities to your platform - some apps have a single function, others have multiple.
For example, in the Avoka Exchange program we have a one project for each external system we integrate with (greenId, ESignLive). In each project we could have up to 5 or 6 services for sending and retrieving data between the systems. These may include dynamic data services, delivery services and scheduled services. The services can utilise common API code to save duplication and a developer making a change to a function has all the assets they need in one place.
There are some considerations from a development perspective:
I would not advocate having every service in its own project as a rule, nor would I recommend grouping services into projects based on their type (E.g Dynamic Data services in one project and Delivery services in another).
that's encouraging; I was thinking of the 'related services' concept as well - just trying to deal with how to implement it.
I was thinking of putting GreenID in one project, Mastersoft in another and then put services for each form together - prefill, saved, completed, delivery.
I'll consider some of your other points as well as I work through how best to architect our code base.
Thanks fro the feedback.
Yes, that makes sense. Sometimes you need to develop a service targeting a specific form, although as much as practical you should design your services such that they are reusable across many forms. The use of service parameters to drive configuration options helps with this.
Please see the documentation below:
Avoka Transact Fluent SDK
The Transact Project Template
This has being used by the Avoka Exhange Team for developing their Fluent services, and is our current best practice.
I have read that documentation and followed the examples to create a project template. It is working well at this stage. I have created a project and created a new service.
So, I'm on the right track.
I was looking at the next level up from a single project and wondering about the whole package of scripts/services for our overall application.
Thanks for the feedback, it's all useful information.