InfoQ Homepage Domain Driven Design Content on InfoQ
-
/articles/cell-based-architecture-2024-series/en/smallimage/small-series-logo-1728400245988.jpg)
Article Series: Cell-Based Architectures: How to Build Scalable and Resilient Systems
In this article series, we take readers on a journey of discovery and provide a comprehensive overview and in-depth analysis of many key aspects of cell-based architectures, as well as practical advice for applying this approach to existing and new architectures.
-
/articles/cell-based-architecture-distributed-systems/en/smallimage/how-cell-based-arhitecture-logo-small-1728382176391.jpg)
How Cell-Based Architecture Enhances Modern Distributed Systems
Cell-based architecture has emerged as a response to many challenges associated with distributed systems. It employs the bulkhead pattern to isolate failures to a fraction of the affected infrastructure footprint and prevent widespread impact. Cells can also help organize large architectures into domain-bound deployment and delivery units, which provides essential sociotechnical benefits.
-
/articles/set-piece-strategy-sheen-brisals/en/smallimage/TheSetPieceStrategyTacklingComplexityinServerlessApplications-small-1719579748745.jpg)
The Set Piece Strategy: Tackling Complexity in Serverless Applications
In this article, senior engineering manager and AWS Serverless hero Sheen Brisals examines how the characteristics of serverless such as optimization, robust availability and scalability influence us to think in a new way of architecting and evolving modern applications as set pieces, a concept from moviemaking. The contents of this article were presented during QCon London 2024.
-
/articles/replace-process-dogma-engineering/en/smallimage/agile-rehab-replacing-process-dogma-with-engineering-to-achieve-true-agility-small-1698326538210.jpg)
Agile Rehab: Replacing Process Dogma with Engineering to Achieve True Agility
Struggling with your "agile transformation?" Is your scaling framework not providing the outcomes you hoped for? In this article, we’ll discuss how teams in a large enterprise replaced heavy agile processes with Conway’s Law and better engineering to migrate from quarterly to daily value delivery to the end users.
-
/articles/domain-driven-cloud/en/smallimage/domain-driven-cloud-aligning-your-cloud-architecture-to-your-business-model-small-1694509389452.jpg)
Domain-Driven Cloud: Aligning Your Cloud Architecture to Your Business Model
Domain-Driven Cloud (DDC) is an approach for creating your organization’s cloud architecture based on your business model. Based on Domain-Driven Design (DDD) and the architecture principle of high cohesion and low coupling, this article introduces DDC including the technical and human benefits of aligning your cloud architecture to the bounded contexts in your business model.
-
/articles/adaptive-socio-technical-systems-flow/en/smallimage/adaptive-socio-technical-systems-with-architecture-for-flow-small-1688719131680.jpg)
Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies
Designing for adaptability sounds easier than done. How do you design and build systems that can evolve and thrive in the face of constant change? This article provides a high-level introduction to combining Wardley Mapping, Domain-Driven Design (DDD), and Team Topologies to design and build adaptive, socio-technical systems optimized for a fast flow of change.
-
/articles/exploring-java-records/en/smallimage/exploring-java-records-beyond-data-transfer-objects-small-1686735777145.jpg)
Exploring Java Records beyond Data Transfer Objects
Records are a concise and easy-to-use syntax for creating immutable classes. By using Records, you can ensure that your APIs are bulletproof and less prone to errors. Additionally, Records can be applied with Domain-Driven Design (DDD) principles to create more robust and maintainable code. Learning to use Records and apply them with DDD can help you make more resilient and scalable applications.
-
/articles/architecture-modernization-domain-driven-discovery/en/smallimage/start-your-architecture-modernization-with-domain-driven-discovery-small-1683106490819.jpg)
Start Your Architecture Modernization with Domain-Driven Discovery
Successful projects start with robust discovery. What if your project is modernizing your tangled old legacy system or migrating all your workloads to the cloud? This article presents a guided approach to starting your next architecture modernization project with a Domain-Driven Discovery (DDD), illustrated with a medical supply company that is migrating its core systems to the cloud.
-
/articles/devops-not-enough-scaling-tech-driven-organizations/en/smallimage/logo-1617086584261.jpg)
DevOps is Not Enough for Scaling and Evolving Tech-Driven Organizations: a Q&A with Eduardo da Silva
Eduardo Silva from bol.com on the need for sociotechnical systems thinking. DevOps is a good starting point but a wider view of the organization as a sociotechnical system is key for sustained growth.
-
/articles/value-test-coach/en/smallimage/logo-1588108384388.jpg)
The Value and Purpose of a Test Coach
Introducing business-oriented automated testing can involve a huge cultural change. For this we really need a Test Coach role, just like we have agile coaches and scrum masters. In this article we hear from someone living this new role, using Domain Oriented Testing on a daily basis to ensure acceptance tests have full story coverage, and unit tests verify business behavior, not implementation.
-
/articles/modeling-uncertainty-reactive-ddd/en/smallimage/modeling-uncertainty-reactive-ddd-s-1538047373293.jpeg)
Modeling Uncertainty with Reactive DDD
Vaughn Vernon has written several books on DDD and reactive messaging patterns, and has found that the nature of distributed systems means you must deal with uncertainty. How to respond to a missing message, or a message that is received twice, should be a business decision, and therefore must be part of the domain model.
-
/articles/ddd-do-over/en/smallimage/ddd-do-over-s-1536958878552.jpeg)
The DDD Do-Over
Jimmy Bogard had a rare opportunity to do what many developers want after finishing a tough project -- a do-over. His team worked on two very similar projects, both using DDD. He discusses the lessons learned from the first project and how the team avoided common pitfalls and was more successful on their later project.