What role does domain driven design play in microservices architecture?

DDD concepts apply to SOA in general, not only to the specializations like Microservices. If you decompose your system logically, following DDD - you might have an implementation where a 'modular' monolith behaves in the same way as microservices would - as long as you respect the bounded context within the monolith. The idea is that each domain provides application services to other domains (SOA) - irrespective of how granular the physical code constructs are.

DDD is its core, it attacks the complexity at the heart of the software, and translates the business need in an organized way, down to the ideal level of granularity for a specific service.

Bounded contexts help to define the limits of each domain, and the rules for interaction and sharing of information between domains, they are the foundation of DDD, and must be designed with great care.

DDD and microservices architecture are both popular approaches for handling complex, large-scale systems. They intersect through the concept of bounded contexts. - A bounded context is a conceptual boundary within which a specific domain model is defined and applicable. - Each microservice is responsible for a specific bounded context. - Both concepts promotes autonomy and decoupling. - The consistency boundary of a bounded context matches well with the consistency boundary of a microservice - Both concepts support the independent evolution of different parts of the system

DDD in strategic design becomes especially relevant when defining your organizational structures. When applying Conway's Law to DDD, we see that the organization's structure and communication patterns can impact how bounded contexts are defined and implemented. If an organization is structured into siloed teams, this could lead to the creation of bounded contexts that align with these organizational divisions. Conway's Law further implies that teams with a high degree of autonomy are likely to produce more cohesive and well-defined bounded contexts. Strategic design starts with the structure of the business long before the specific way those business unit will provide (micro) services to each other.

Una pieza clave del DDD es el Lenguaje Ubicuo, el cual permite normalizar los términos para que las áreas de negocio y los técnicos puedan comunicar sus ideas con coherencia, mejorando la comunicación de los equipos para lograr alcanzar e implementar los objetivos de negocio. Sin un marco común de referencia a veces los proyectos pueden quedar muy subjetivos y terminar en implementaciones inadecuadas.

The ubiquitous language is decisive for the success of a DDD implementation, in its workload, as it unifies in a single language, business desires, together with technical jargon originating from its business specificity, between technical and non-technical teams.

With microservices, each app could have its own CI/CD cycle, so teams can work independently without interfering with other apps. This can speed up development and reduce the time it takes to deploy code changes. With ubiquitous language in place for DDD, CI/CD just makes it better in terms of software quality, customer satisfaction. It also improves application security and adds value to use automation testing that could catch errors earlier and helps in reliable code coverage through testing.

CI simply makes it easier to manage and deploy Microservices independently from each other. While bounded contexts define logical boundaries in microservices, it aligns with CI by enabling focused & continuous development within each of the domains. CI also helps to ensure each microservice is respected within its bounded context, giving you clean interfaces and interactions between domains.

Event storming can be used to help break a system down into different functional areas or domains that can then be translated into micro-services. It's a good technique to use when you want to understand at a high level what some of the micro-services should be and how they should interact with each other.

In the context of business architecture, especially in healthcare, DDD can play a critical role in aligning technology with business goals and improving user experience. Another key concept would be Entities and Value Objects: Entities are objects that have a distinct identity (e.g., a patient or a healthcare provider), while value objects represent descriptive aspects of the domain (e.g., a patient’s address).

Looking at the future of DDD, I believe the approach to stay relevant long after we have left Microservices behind. Event Driven Architecture in conjunction with a Datamesh approach has very much surpassed Microservices and centralized datastores. We already see DDD stay relevant in Event Driven Architecture, while Datamesh is basically DDD in a 'data trench-coat'.