Let's imagine an application where users can work collaboratively on projects. There's a project listing where a user can subscribe to a project, and a coworking screen where multiple users can work on a project.

So far I have identified the core domain, "coworking", and a subdomain, "collaboration project listing".

Both project and user need some sort of backend, where user settings can be edited and projects can be created/edited. I haven't really got a clue, so I identified this as a subdomain "backend", which seems too abstract, because it doesn't describe any sort of business domain. Data from backend is needed by both domains that I mentioned above, so I'm hesitant to attach the backend to either of those.

Is it legitimate to have a "backend" subdomain or is it an indication that my domains are not clearly defined?

  • "The backend" looks like an implementation detail and a distraction. Would your users, customers, business stakeholders, etc. even know what it means?
    – Alexander
    Jul 1 '21 at 16:05
  • @Alexander If it's not a subdomain, what is it then? If it's an implementation detail - belonging to which domain?
    – Hans
    Jul 1 '21 at 16:19
  • Is your backend just a data store or is it more like a service that provides some of the business logic to be accessed by the front end? In the latter case, you can almost think about the backend as being a separate application, with its own core domain and subdomains that you can map in some way to modules, collaborating within it. Otherwise, it's basically a database with a custom pass-through API, and your domain is embodied almost entirely on the client side, where you might have a (semi-)generic subdomain concerned with accessing this database, modeled as some sort of a DAL. Jul 1 '21 at 22:47
  • @FilipMilovanović At this point, I am unsure whether there will be any business logic applied in the backend. There surely will be validation of ie. project title length. So right now I tend to agree with the second possibility of a simple API that provides access for the other domains to hydrate their domain models.
    – Hans
    Jul 2 '21 at 10:07

Your project/user management domain sounds like a legit "Supporting domain" to your collaboration "Core domain." Separating this simplistic CRUD-like functionality from the collaboration domain is a good idea and is encouraged by DDD. You might want to call it something more meaningful (as the functionality emerges over time) than the "backend."

A Domain in DDD need not be architected in DDD, CQRS, or EventSourcing principles, nor does it need to have complex business rules. Its needs and functionality dictate the architecture of the domain. So a CRUD domain to configuration or management data is still a domain.

Architecting your entire product (containing multiple domains and bounded contexts) in the same pattern is actually an anti-pattern. You wouldn't want to waste time and energy, nor would it be a good fit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.