Pulling Together

DDD and Teams

Agile approaches rely on cross-functional teams. In teams, all roles gather to implement a business-relevant feature. The team will include developers with different orientations such as at the front end or the back end. Other roles can also exist such as user experience (UX) experts or operations specialists.

DDD comes to similar conclusions from different directions. It divides a software system into bounded contexts, behind which are business modules that integrate a specific, separate business functionality (e.g., invoicing or taking orders). These modules are significant in terms of analysis, as well, because specific technical terms apply in a bounded context. Accounting includes terms such as "tax" and "debt collection."

At first, it seems that bounded contexts simply define the structure of the software. But appearances are deceptive: DDD gives them a role in the project's organization. Ideally, one team will take care of one bounded context. Because the team is responsible for the specific bounded context and therefore also for the domain-oriented functionality implemented in it, the team can autonomously make certain domain-oriented changes.

Cross-functional teams are based on the same idea. You would build a team such that it can implement business features on its own, if possible. Agility focuses on the composition of the team, and ideally it should reflect all roles. DDD, on the other hand, focuses on the division of the software, which needs to proceed such that each team can implement independent functionality. As soon as you combine the two concepts, cross-functional teams emerge that work on a bounded context and cover the business facts in full (Figure 2).

Figure 2: A cross-functional team works on a bounded context.

Such teams comprise five to eight people who develop software together. However, systems often turn out to be so large that a single team cannot handle the work involved, so you will end up coordinating several teams. In this case, DDD provides for relationships that result from bounded contexts that you can assign to teams (Figure 3).

Figure 3: The two types of relationships between teams in DDD – customer-supplier and conformist – follow different rules.

When a team needs help from another team to implement features in its own bounded context, it enters into a customer-supplier relationship. As the customer, the team requests functions from the other team, which then assumes the supplier role. Formulated in the context of this example, one team takes care of invoicing and needs support from the team that takes orders. Without an interface that provides information about the order, it is almost impossible to write an invoice. The customer team communicates the necessary features, and the two teams then negotiate the necessary tasks and schedule for delivery.

In the conformist alternative, the team cannot request anything but adapts to what is offered. This situation might occur if the other team is looking after legacy software that is no longer maintainable and therefore simply cannot meet specific requirements. If the order-taking software cannot be changed, the invoicing team will find itself in a conformist role, with the corresponding implications for the development of the software.

Strictly speaking, these relationships exist at the bounded context level, which means that as soon as another team takes responsibility for a bounded context, it also has the associated role (e.g., customer or conformist).

Once again, DDD and agility complement each other. Autonomous teams that can meet technical requirements as independently as possible are supported by patterns because they can now request help from other teams. These patterns rely on a decentralized organization. After defining a customer-supplier relationship, teams can interact in line with that relationship. Central coordination, as envisaged by some approaches to scaling agile methods, is no longer needed in this case.

The team topology [5] describes further relationships between teams. It extends these ideas to include constructs such as platform teams, which are not responsible for a technical part of the system such as a bounded context, but instead offer a platform that provides technical features on which other teams can build.

Humans, Not Robots

All of these patterns and practices in both DDD and agile development have an effect on the formal organization. Accordingly, they would be reflected in an organizational chart, but people don't always follow organizational charts. Just because it says somewhere that one team should help another team doesn't mean that employees will actually behave that way. They all know ways to get around reorganization or instructions from management.

When this situation transpires, an important idea from the Agile Manifesto takes hold. Individuals and interactions play a more important role than processes and tools. This statement can be interpreted as meaning that formal collaborations, such as those established by DDD or team topologies, do not matter as much as the actual interactions of individuals. The work of many agile coaches or scrum masters focuses on improving these interactions and interpersonal relationships because both are critical to the success of agile implementation.

The term "sociotechnical system" has become established in the field of DDD and means not only considering the software but also the organization that develops the software system. Experience shows that problems in projects mainly occur in the interaction between the organization and the software. Additionally, organizations and people react very differently to measures such as reorganization, whereas software is essentially deterministic and can be implemented by an engineering approach.

Fact and Fiction

Therefore, DDD and agile development face a very similar problem: Ideas only appear to be realized. The term "cargo cult" is used in this context. Cargo cult manifested with the inhabitants of Pacific Islanders who watched American planes carrying goods to the islands during World War II. However, they did not understand the context, so after the Americans left the islands and more goods failed to arrive, the islanders built runways or headphones to mimic the Americans' behavior – in the hope of receiving deliveries.

In the case of cargo cult agility, you can hold all scrum meetings without following the Agile Manifesto and the values defined therein, including, among other things, generating business value, close cooperation between subject matter experts and developers, and process optimization. Thanks to DDD, you can use the techniques (i.e., decompose a system into bounded contexts) without aligning the architecture with the business value or genuinely understanding and optimally supporting the business meaning of the system.

The risk of implementing DDD or agile development in this way exists because these superficial activities are easy to review and easy to implement compared with agile values. Working on the orientation of the project, the architecture, or the values requires far more effort. Additionally, you will find it much more difficult to identify whether these values or the desired alignment has been achieved.

Collaborative modeling is a practical technique from DDD and a good example of the different levels. At first glance, it is simply a matter of creating an artifact; for example, event storming yields an overview of all the events in a given business context. As a concrete, tangible effect, the end result is an artifact that possesses a specific quality.

At the same time, when people interact with each other in the event storming process, the tensions or alliances that exist in the organization are revealed, as well as which people have particularly detailed knowledge in which areas. Moreover, participants can practice collaborating on a problem during an event-storming session.