The answer to your question "So is this structure correct?" can only be known by analysing your goals in contrast with your strategy for libs.
First you need to know: "What are the main reasons Nx promotes more smaller libraries?".
- To my understanding the main reason is for their tooling to save you as much time during building, testing, analysis-tooling and deployment. Their tooling checks if something has been affected and with smaller targets to run the process gets quicker and easier to do.
- The second reason is as you state that it can help you share your code in multiple projects, apps or libaries if the need should arise. Simmilarly you can also restrict use of libraries between eachother.
- Having a structure also allows developers to more easliy find what they need or check if something already exists they can use. Given the nature of a monorepo tends to get quite big this helps not overwhelm developers.
So, you can choose your own strategy or a known one like DDD - https://github.com/manfredsteyer/2019_08_26/blob/master/tddd_en.md). But to determine if your strategy is solid for your goals you need to consider: "Is this library supporting my strategy?".
To figure out what strategy you want is kind of complex and to be honest after some time you most likely will find that you can seperate things or put things into one library later down the road. This is common.
If i was to put my critial mind towards your setup ideas i would float to figure out if that strategy is working for me would be something like:
- Your libs/ui/ directory containing components and style. Could it be the case that you would like to have more than one project or app where you have differently styled components? Or should it be same components but with different coloring. If its the latter i would continue with your current approach but if it was the former i would consider sperating it more. I have been in a project where we used one place for components ui and many components became VERY big because they had to act and look differently in multiple apps. Dividing them into smaller libs contains the 'affected' libs and even your manual testing in the end would be less.
- Your libs/data-access/ you use the word 'api' in all folders and you also comment models and services. Is this a candidate for more spereation? Should it be divided into languages and then domain specific services and their related model?