How To Structure Your DDD Project In A Smart Way?

[@aaronprohaska4117]

When you have a class that is the same name as the folder/namespace there will be an error like "ClassName is a namespace but used like a type". How do you handle having a class with the same name as the namespace?

[@AlanBem]

Enums are VOs - they are compared by value

[@onedev7316]

Nice one. Thank you. Can you please do a video/blog on the concept of User Impersonation using identity/Jwt?

[@Codewrinkles]

I plan to do an entire series on Authentication & Authorization. But first I need to get the DDD part out of the way :)

[@onedev7316]

@@Codewrinkles Thank you cant wait. I also followed you Clean Architecture with CQRS. Very helpful

[@eugene_potashkin]

@@Codewrinkles will be great to do Authentication & Authorization in the concept of modular monolith =)

[@mehdi-vl5nn]

There is an article on the Microsoft website that suggests a structure for DDD (Domain-Driven Design) projects, but is such a structure mentioned in well-known DDD resources? It seems more similar to the Clean Architecture.

[@kiddonouka]

Can you create a playlist or tutorial a straightforward website for beginners Because we cant follow up which techniques should we follow. Ex. Creating a website using api with simple Architecture that a beginners can follow.

[@Codewrinkles]

You mean like this one? kzbin.info/www/bejne/iIPVpHl7a7SLd7M

[@RenegadeVile]

Wouldn't the SharedKernel be at risk of becoming very bloated as a project grows? Or would you use sub-folders there to organize them further?

[@Codewrinkles]

First of, the shared kernel would probably be placed in a dedicated project first. Then you can have a shared kernel for the entire domain (own project) and common data structures that are used only within a certain bounded contexts. So this has the potential to be split in a very granular way.

[@RenegadeVile]

@@Codewrinkles Makes sense, and that shared kernel being in its own project might make it reusable for other projects too, at least some classes in there that can be separated and made more generic.

[@simonecambursano9266]

What about dtos? Should they be placed in the domain layer as well?

[@Codewrinkles]

For sure not. By definition, DTOs don't have anything to do with the business logic/rules. As the name implies, they are data transfer objects and therefore not something that would belong in the domain.

[@youssefjari5259]

@@Codewrinkles Would it make sense to put dtos and exceptions in a separate contracts project ?

[@Codewrinkles]

@@youssefjari5259 Of course. But for sure not in the Domain project.

[@Codewrinkles]

@@youssefjari5259 Only if you want to re-use them. I know that some folks do that, but I don't see the intrinsic value in doing so.

[@youssefjari5259]

@@Codewrinkles Since i have a chance to talk to you i'd like to ask you another question (if you have the time to answer it of course). I am designing an application that should be configurable as a modular monolith or be broken into microservices (configurable through a cli) and my approach is to create a domain, application, infrastructure, contract and presentation project for each service. When configured as a monolith the projects of each service would be contained in the same solution and injected in a common api project. The data of each service would be persisted in its own schema within a shared database. In case i decide to split some services or the whole monolith, then i would import only the projects i need in their solution and inject them to the api project of the service with a separate db. I am worried that having too many classlibs contained within a single solution / vps might harm the performance. Is it fine to have 70+ projects that are injected to the same api and compiled together? (i understand that the compile time might be longer but is there anything else i should worry about?)