How to structure multiple features inside a single domain using DDD — does the plugin support feature-level vertical slices?

[wizardnet972]

Hi @manfredsteyer @L-X-T 👋

I’m using the Nx DDD plugin and I have a question about the recommended structure when a domain contains many features.

Today, a domain library often ends up looking like this:

libs/portfolio/domain/
  application/
    feature-a.facade.ts
    feature-b.facade.ts
  infra/
    feature-a.api.ts
    feature-b.api.ts
  ...

This means all application logic for all features lives inside a single application/ folder.
From a DDD perspective this is fine, but from a vertical slice perspective it feels wrong, because each feature does not have its own self-contained slice.

My question

Does the DDD approach (as you teach it) support — or even encourage — having multiple feature-level vertical slices inside one domain?

Something like:

libs/portfolio/feature-plan-list/
  application/
  infra/
  ui/

libs/portfolio/feature-portfolio-edit/
  application/
  infra/
  ui/

Where each feature contains everything it needs, without mixing with other features.

What I’m trying to understand

• Should a domain with many features have multiple feature libs, each representing a vertical slice?
• Or should all feature application logic stay inside a single domain lib under application/, infra/, etc.?
• What is your recommended best practice for large domains with many separate capabilities?

Thanks!
Looking forward to your guidance 🙏

---

If you want, I can also generate:

✅ a shorter version
✅ a more opinionated version
✅ or add diagrams / examples

Just tell me.

[L-X-T]

Hi @wizardnet972, and sorry for the late answer.

I think we dont have a clear answer to that question, so I leave it up to you to decide 😅

As you wrote in your first example our official approach is to put all the services into the domain.

I, personally, try to put the (especially application but also API) services as local as they can be. So if they are used by a component, I'll put it in there, if they are used by a library or group of comp (former NgModule), I'll put it there, and if they are used globally I'll put them into the global services folder.

So, it's not about being super strict, but whatever works best for you and your team!