Skip to content

Latest commit

 

History

History
17 lines (12 loc) · 2.73 KB

domain-driven-design-(ddd).md

File metadata and controls

17 lines (12 loc) · 2.73 KB
Raw

Domain-Driven Design (DDD)

The enterprise is a complex landscape of digital activit.Domain-driven design, or DDD, has emerged to help enterprise architects and other stakeholders define, organize, and communicate about all of the digital resources, capabilities, and experiences across the business. DDD allows business and technology leaders to establish better alignment and clarity across operations, providing the vocabulary, patterns, and standards that enable teams to build reliable, consistent software using APIs.

Elements

  • Models - Models are software abstractions that describe business logic. Developing models helps narrow the divide between code and a description of business operations and value, providing us with a way of quantifying the digital resources we use across APIs.

  • Bounded Contexts - We define enterprise operations as large models by dividing them into different bounded contexts, while being clear about their interrelationships. That provides meaningful segmentation that transcends legacy tribal boundaries.

  • Command Query Responsibility Segregation (CQRS) - A CQRS approach allows you to use different models for updating or reading information, providing more abstractions, and in some cases, more complexity.

  • Ubiquitous Language - Ubiquitous Language is the practice of building a common, rigorous language between developers, users, and business stakeholders, ensuring that everyone involved with API operations is on the same page and uses a common vocabulary.

  • Microservices - Using micrservices means designing software applications as suites of independently deployable services. These services can include business capabilities, automated deployments, and business intelligence. Microservices provide decentralized control of languages and data.

  • Dependencies - DDD helps provide an honest and clear view of the dependencies between APIs, mapping the technical ways they work together, while also providing visibility.

  • Patterns - With DDD, you identify existing patterns across the APIs and microservices in use. Then you can spread the use of these patterns across teams, while working to introduce new healthy patterns into regular team workflows.

  • Experts - Domain experts should always have a seat at the table in modeling business operations. They help segregate responsibility and define the Ubiquitous Language you use. Including them ensures that the business domain always has a voice.

Domain-driven design isn’t just about these tangible elements.Iit is about enabling your teams and articulating the domains you are operating in. That will translate into the overall design and experience of your APIs. DDD represents the order (or chaos) that exists across API operations.