I have been asked by the BA/PM community in my company how DDD/domain modelling can be used as a tool when deciding how to form, split teams and how to decide their missions.

I have my own thoughts on this, mostly realising DDD was not meant as a tool for team composition. However, I wouldn't rule out using the outputs of domain modelling/mapping as input for staff allocation decision making. I'd like to know if this matter has been treated by any of the subject experts before.

In more general terms, how to win the BA/PM community to realise DDD/domain modelling is useful.

2 Answers 2


DDD is about design. It is therefore not necessarily the primary source to decide about teams. However, DDD can be related to team structure when it comes to bounded context.

A bounded context itself is independent of the team structure. It corresponds to some part of the larger domain model/subdomain. But the boundaries are set in a way that implies more interaction/exchanges/teamwork between people involved in the same context than with people outside the context. This makes bounded contexts relevant for organising teams.

In this regard, Eric Evans ("inventor" of DDD), addressed some context mapping techniques with a BC-driven team structure in mind (e.g. Partnership, Customer/Supplier Development, Conformist, that specifically mention team relationships).

So, it seems reasonable to think of each team managing a group of bounded contexts. There can even be synergies with other other domain driven approaches such as the popular microservice splitting pattern by sub-domain or microfrontends.

  • Bounded context, from the domain knowledge pure and strictly speaking. Not technical boundaries. That only leads to backend developers vs frontend developers vs DevOpers vs Product developers, etc.
    – Laiv
    Nov 10, 2022 at 13:13
  • @Laiv thank you for the opportunity to clarify. My position is not at all to promote a team structure by bounded context. There are many cases where it’s not the best fit. However when there is a good fit, for example with highly specialised enterprise applications, the bounded context would be the basic DDD block.
    – Christophe
    Nov 10, 2022 at 19:25
  • @Laiv there are domains where some groups of bounded context correspond directly to specialized domain knowledge, but also indirectly to specialized application/module knowlegde and even technical topics (e.g microfrontends for internet sales, scanning and tracking devices for warehouse management, B2B e-procurement protocols for inbound logistics, and specialized HR packaged). Organizalional system dynamics explain then a natural clustering of teams along these boundaries.
    – Christophe
    Nov 10, 2022 at 19:43

I would recommend looking at Team Topologies and Org Topologies.

Like Christophe mentioned, you could use Bounded Contexts and form what Team Topologies would call a Complicated Subsystem Team or an Enabling Team.

However, aligning teams with a Bounded Context may not be the best solution since it very well could prevent you from implementing a Stream-Aligned Team. A Stream-Aligned Team that is focused on a particular group of customers or users that can get a deep understanding of those stakeholders, and this deep understanding would help them deliver useful, valuable changes to the product.

I would be careful with using DDD to define teams. It may be more useful to define potential dependencies between streams or highlight where an Enabling Team or Complicated Subsystem Team could be useful. However, my experience tells me that Stream-Aligned Teams are often a good choice, and these teams will cut across multiple Bounded Contexts.

  • +1 just for "I would be careful with using DDD to define teams." Developers routinely try to co-opt DDD for things it wasn't intended. Nov 10, 2022 at 13:53
  • @RobertHarvey You are completely right. I answered the question because OP prudently asked “how … can … “ and not “how … must…”. For some kind of domains, like highly specialized enterprise applications, the bounded context may correspond to a natural border. But there are plenty of situations where this is not the best fit.
    – Christophe
    Nov 10, 2022 at 19:20
  • @Christophe Yes. Those Bounded Contexts would be, IMO, a good fit for what Team Topologies calls a Complicated Subsystem Team. So there is definitely value in mapping out your system, including the subsystems and components and drawing the Bounded Contexts. I would be very worried about an organization that just wants to blindly assign teams to Bounded Contexts, though.
    – Thomas Owens
    Nov 10, 2022 at 20:04
  • @ThomasOwens I cannot really agree with this terminology. Complicated means “difficult to understand”, whereas DDD should simplify the understanding and alignig teams on bc make it even more straightforward to understand ;-)
    – Christophe
    Nov 11, 2022 at 17:46
  • @Christophe That's what is meant. Team Topologies says that you use a Complicated Subsystem Team "where significant mathematics/calculation/technical expertise is needed". The subsystem is complicated. In DDD, a Bounded Context is where a particular domain model applies, your domain model would be complicated and require significant expertse to understand and work with.
    – Thomas Owens
    Nov 11, 2022 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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