Application of the Conway's law in domain driven design

Introduction

Melvin E. Conway stated the following:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

There are many ways to interpret this. Let's see.

Software architecture as a mirror of the organization structure

One of the obvious interpretations of this statement is that software designers use it to design their systems mirroring the organization structure because, when they capture the requirements, the different stakeholders communicate it the same way they are used to working daily. Many times, then, you find modules inside the software that replicates the different departments of the company, processes that replicate the physical, manual processes people do, etc. Or, when it comes to websites, you find information structures that have more to do with the internal organization of the communication than with the needs of the actual users.

Let's walk the other way around: organizations being structured like the software's internal structure

Do you think software can influence a company's internal organization? Think about microservices architecture. If you design the software considering the domain, rather than the organization of the company, and then you create one microservice per subdomain, and then you create a development squad per microservice... aren't you just shaping the company's organization by mirroring the software's internal structure? Add product owners per microservice, QA's... you are effectively shaping the company.

Conclusion

Conway's law is interesting as it shows us the tight relationship between software and organizations. While the organization structure can influence software architecture, the other way around is also possible.