hjwp
commented
2 weeks ago hi! i can't find an explanation of "feature-based" arch on that link, but yes you'd probably want a different folder structure once the number of domains starts to increase.
certainly if your project starts to contain several different Bounded Contexts in a DDD sense, you'd want to keep the domain models and repositories for those in separate folders, maybe even separate packages. then you might think about keeping some of the shared code for "plumbing" or "infrastructure" stuff like, how to get db sessions, maybe a base class for a UoW or a message bus, in a shared location that can be access from all the different domains. at some point you might even decide that different domains / bounded contexts have different databases or persistent storage mechanisms, so that's something to think about.
another thing you might start to see reflected in the folder hierarchy is that one Bounded Context may have several different domain models, but a common set of usecases / service layer functions / command handlers, that can talk to all the models within that context. but (and as always, It Depends) you probably wouldn't expect a usecase or command handler from one bounded context to be able to see any of the models in a separate bounded context. if you need to exchange data between bounded contexts, you could consider some of the patterns in the DDD blue book like anticorruption layer.
not sure if that all helps?
Thank you very much for such high-quality material. It really allows you to look at the development process from a different angle. However, I am interested in discussing the following point. Yes, the number of domains is extremely small now, but what if we deal with a dozen entities. How will the project structure be formed with the increase in the number of domain packages? In this case, is it wise to use a hybrid between Feature-Based and Hexagonal Architecture?