DDD Bounded Contexts with Onion Architecture

1
votes

I have the following Onion Architecture framework.

  • Domain
    • Entities - For my domain entities
    • Interfaces - For my domain interfaces
    • Services - For my domain services
  • Infrastructure
    • Data - For Fluent NHibernate persistence
    • Interfaces - For infrastructure interfaces
    • Logging - Just an interface for logging in case I want to switch out my logging library to something else.
    • Dependency Resolution - Most of my IoC registrations goes in here.
  • Services
    • Interfaces - Application service interfaces goes in here, they will get implemented in the UI project.
  • Tests
    • Infrastructure Tests - For testing infrastructure services etc.
    • Domain Tests - For testing domain models and services
  • Web
    • UI - User interface project where I implement application services, user interface, etc ...

With Domain Driven Development one would identify the Bounded Contexts. Most of the literature on the internet states that each Bounded Context needs to be abstracted into their own project or namespace.

  1. Is my approach then incorrect for having all my Domain Models in one project and all my Domain Services in another project? Does it really matter not having different bounded context's in different namespaces or projects?
  2. If you have a Model A which is used my Bounded Context A, but Bounded Context B, Bounded Context C, etc also needs to use the exact same Model A, Do you allow them to use that exact same model, or do you create a new model for each Bounded Context?

I am new to DDD so sorry if this question is a dumb question. I find myself understanding something better if I ask a question and get a good explanation as an answer.

Any Help will be much appreciated.

1
c#design-patternsarchitecturedomain-driven-designonion-architecture

1 Answers

8
votes

Is my approach then incorrect for having all my Domain Models in one project and all my Domain Services in another project? Does it really matter not having different bounded context's in different namespaces or projects?

  1. Different namespaces is a conceptual and a practical solution, since otherwise you could have entity name collision when two neighboring concepts go by the same name in different subdomains.

    Different projects/solutions is more of an organizational choice on top of that. It makes things a bit easier if separate teams work on the BC's, and the separate binaries mean the BC's are more independently deployable.

If you have a Model A which is used my Bounded Context A, but Bounded Context B, Bounded Context C, etc also needs to use the exact same Model A, Do you allow them to use that exact same model, or do you create a new model for each Bounded Context?

  1. It would require some more domain analysis to tell, but the whole point of a Bounded Context is being able to view things from a totally different angle. In the rare cases when

    • the exact same entity is used in 3 different BC's
    • you don't see them evolving their own way in the future
    • the entity doesn't seem to naturally belong in a given BC

then you might want to use the Shared Kernel pattern. Otherwise, just copy the entity in each BC and let those live their own lives, or find the entity's true BC and link to its ID from other BC's.