Question 1: Assuming you have a complex business domain and significant business logic, it can be worth making the effort as you have to isolate your domain layer from infrastructure concerns. However, this is often not the case. If you are mostly just moving data from the database to the UI and back again, then this is overengineering and you should seek something with fewer moving parts.
Question 2: How many distinct domain models (with different ubiquitous languages) do you have? One? Two? Three? For each model, isolate it from other models and infrastructure concerns as much as possible.
Eric Evans defines a bounded context as primarily a linguistic boundary (quote from his book):
A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Within that CONTEXT, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other CONTEXTS, other models apply, with differences in terminology, in concepts and rules, and in dialects of the UBIQUITOUS LANGUAGE.
DBContext may point you in the right direction, but remember it is an infrastructure artifact, not a domain concept. It "represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit."_ (from MSDN Docs).
DDD is about domain modeling: using models to solve hard business problems in complex business domains. Deriving model boundaries from technical considerations can feel like the tail wagging the dog. Define the boundary of your model conceptually, then align your technical infrastructure accordingly.
Question 3: DTO's can be a good way to enforce a context boundary, such as for an API. The API can then function as an anti-corruption layer to other models. The reason people typically use them for UIs is to avoid having to bleed UI concepts into the domain model.
Don't seek a perfect architecture. And realize that "best practices" are really just guidelines based on particular situations. Follow the guidelines other more experienced people have laid out, with the understanding that your situation is likely subtly different. Use what you have with the expectation of refactoring your design decisions when you find friction. For example, if later you find that the DTOs to the UI are overkill, then remove them. Simplify wherever you can.