On #1, it kind of depends on the location and purpose of the service and the relationship between them. In C# Web API services I've done both REST and MSMQ. The goal was to make how it was used relatively transparent and switchable via a repository pattern. If I needed to, I could even swap in a plain old DLL to do the work.
On #2, when I was was working with an Oracle backend services had their own schemas with matching stored procedure packages. They might be accessing the same data tables underneath (usually legacy or common data ones) but the services and their callers wouldn't know that. Everything would appear separate at their level. In SQL Server, you can do a similar things with separate databases.
Some tables do need to be shared. DRY should apply to databases as well. You (or your DBA) don't want to find yourself in the position of having to maintain dozens of customer tables, zip/postal code tables, tax tables and so forth. Data will get out of sync and cause you considerable headaches. Trying to do this is like cutting and pasting code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On #1, it kind of depends on the location and purpose of the service and the relationship between them. In C# Web API services I've done both REST and MSMQ. The goal was to make how it was used relatively transparent and switchable via a repository pattern. If I needed to, I could even swap in a plain old DLL to do the work.
On #2, when I was was working with an Oracle backend services had their own schemas with matching stored procedure packages. They might be accessing the same data tables underneath (usually legacy or common data ones) but the services and their callers wouldn't know that. Everything would appear separate at their level. In SQL Server, you can do a similar things with separate databases.
Some tables do need to be shared. DRY should apply to databases as well. You (or your DBA) don't want to find yourself in the position of having to maintain dozens of customer tables, zip/postal code tables, tax tables and so forth. Data will get out of sync and cause you considerable headaches. Trying to do this is like cutting and pasting code.