ok so we are in the process of integrating with a legacy code base that is not maintained anymore so it can be considered stable.

i am torn between exposing a service endpoint (JSON) for our new bounded context to integrate with or just simply creating a component (assembly) that directly talks to the legacy database (sql server) and have my new bounded context reference directly and make calls too (kind of RPC i guess).

any guidance or suggestions on this would be great!

I think both approaches are realistic possibilities. With each approach you are probably going to use an anti-corruption layer to translate from the old system to your new code. As you are probably aware now, this will allow your new code be clean, domain-focused, and able to evolve as you gain new domain insights.

In your situation, I'd expect the most important factors to be how much extra effort is involved, what is your longer-term plan, and what are your schedule requirements.

For example, if you put a JSON API on top of your legacy system, a lot of the business rules and calculations may already be implemented. However, if you go direct to the database, you may have to re-implement them.

But if you do go direct to the database, you have effectively replaced that portion of legacy code, meaning there is less of the legacy system that needs to be maintained, understood, replaced, debugged etc.

However, going to the DB comes at the cost of additional risk - you may not reimplement the new version as-per the old one, and additional time - it may take longer, since you are starting from scratch which may push back the delivery of important business functionality.

I'd expect that in most rewrite scenarios creating a JSON API is likely to take longer to eventually replace the old system, but will allow you to deliver new features sooner and more predictably in the short-term. However, that's not a universal rule.

thanks nick that really helped me make up my mind!