I am creating a project based on DDD principles. I came up with the following while reading the resources on the internet, does that make sense? In particular, parts like:
Shared.Core
project that is shared between bounded contexts.Data
projects for each bounded contextRest.API
that depends on Shared.Core
and FeatureX.Core
projects.The following table shows the projects I have created and their dependencies, ->
denotes 'depends on'.
Rest.API -> Feature1.Core -> Feature1.Data
-> Shared.Core
-> Feature2.Core -> Feature2.Data
-> Shared.Core
-> Shared.Core
You can name the folders whatever you want but it is recommended that:
you have a module/namespace/package/directory that has no dependencies to any infrastructure or technology (like REST, SQL, NOSQL, MONGO etc) where only your business logic should stay; here live the Aggregates, Value objects, Domain services, Sagas etc. At least one for each Bounded context; let's name it the Domain layer. It may not depend on other Domain layers. It should be side-effects free, easy testable.
you may use inside the domain layer shared components but only if they are stateless and general purpose like datetime manipulation libraries, lists, stacks etc.
anti-corruption layers that convert from remote models to local models. Most probable they depend on multiple Domain layers.
other presentation, infrastructure and technology specific libraries and frameworks, IO adapters and ports should be clearly separated from other layers. May depend on the Domain layer.
So, to map to you already have:
Rest.API -> Feature1.Domain -> Shared.Lib
-> Feature1.Infrastructure
-> Feature1.ACL -> Feature1.Infrastructure
-> Feature2.Domain -> Shared.Lib
-> Feature2.Infrastructure
-> Shared.Lib
With the following comments: