Can there be several bounded contexts within one application?
You could choose to organise multiple bounded contexts within a single application, choosing something like namespaces/folders to separate them:
/domain
/Claims
/Policy.cs
/Inspections
/Policy.cs
/Underwriting
/Policy.cs
(this "policy" example is from DDD Distilled)
The advantage of such an approach is simplicity, although it has a number of disadvantages:
- More likely to lead to bleed and contamination between contexts - it takes a lot of discipline to maintain the boundaries as it is too easy to just reference objects from another context if they are all in the same project
- More difficult to manage if multiple teams working on the application
- Less choice when it comes to deployment (may not be an issue)
If so, what determines if a context should be deployed together with another context or if it should be deployed as a stand-alone unit?
You have to consider the advantages and disadvantages of having them in a single application vs splitting them up. Some of these I've already touched on above but there are other things to consider..
Do the different contexts have different non-functional requirements? i.e. scaling, performance needs etc? If so, you'll want to be able to deploy them separately, so they should not be part of the same application.
Are you limited in any way by the technologies you can choose, or the servers you can deploy to? There may be constraints in place that make it more difficult to move to a more microservices style architecture.
There is also an organisational element to this question and it depends on the type of organisation you are in. Do you have multiple teams working on your system? If you are working in an organisation who's primary business is IT based, you will often find the business has already made some decisions for you, by the way they have organised teams and structure (see Conway's law) aligned to contexts. Whether this division is what you actually want / correct is another question. In other organisations, you might be "the IT department" or something more general, in which case, you'll likely have more control over how to model and organise things.
If I have multiple bounded contexts within one application (deployment unit), and a client (for instance a UI) requires information from several contexts at the same time, should I create a new application service in order to support this scenario then?
as @plalx mentions in the comments, you can do this aggregation either client side or server side. Imagine a page with 3 widgets where each widget makes an AJAX call to a different context (if you split them up) and composes the UI this way. Alternatively, you could aggregate server side, i.e. having some sort of read-model for the UI in question.
