For simplicity I’d start with one unless you have a good reason to separate them as it adds complexity, especially if they’re sharing the same Database, from an SOA POV there really should only be a single App/Layer that manages/encapsulates a database.
On the other side if both Apps are unrelated with each other it suggests that the Database should be decoupled and the Apps should be isolated. If you’re going to keep them using the same database then they should be in the same App.
The rationale for which to use is between the Majestic monolith and benefits of SOA (not best link, but 1 I could find off-hand), if you’re interested in learning more about SOA I can recommend Enterprise SOA and closely related is Enterprise Integration Patterns which are 2 seminal books on the subject.
Basically there are lot of factors that go into deciding what to use: modularity and whether they can be easily de-coupled, dev cycle, i.e. whether they’re expected to both be worked on and deployed together, the size of the code-base (small/medium stick to monolith), expertise of dev team, i.e. if all devs frequently work on both keep them together, if devs are assigned to work on different Apps then there will be less friction if they’re working on different code-bases.