I have a given microservice architecture with the following domains. Each domain has excactly one database.
S contains a set of items (books, magazines) which can be sold. Furthermore, value added tax is maintained here. So S contains a service s1 for CRUD on items and CRUD on taxes. Additional it has a jms consuming service s2.
Domain I handles all about selling (invoices, delivery conditions, ...)
So far, I contains a micro service i1 which handles CRUD to invoices (create invoice, list invoice and so on).
I plan, to have another micro service i2 which is an export of csv containing only special information a government official needs.
I am not sure whether to put the new function within i1 or in a new micro service i2.
Sure, an export can always crash and kill also the application. If integrated in i1, the whole I domain might crash. On the other hand I have another application to deploy...
Do you have a bit experience where to make the cut between the services?
Microservices are designed mostly around bounded context (DDD). bounded context can have even more than one microservices. It's all about give and take and there is no right answer. In my opinion as long as services are independent and they aren't interfering each other should be the way to go. in your case i would say go for additional service which is export service. like you mentioned it can impact the exisiting application if deployed within existing app.
It's easier to deploy and manage the service than affecting the existing service and dealing the 2 issues at the same time. the impact on existing service and investigate why export not working. keep them separate. easy to debug and most importantly doesn't impact your running service.
you can also secure it better way or apply additional business rules easily.