Domain Driven Design and SAFe Building Software to meet the Business Needs
Explore the role that Domain Driven Design takes in a Scaled Agile Framework (SAFe) approach:
By Tim Oleson Written with the help of Copilot.
Building software that meets the needs of the business
I wanted to write an article that explored the questions of how does Domain Driven Design work with SAFe Architecture. The reason I wanted to explore this subject is knowing both approaches I had a “AH HAH!” moment where the language of both approaches shared many similarities and meaning.
“Context is King” and in the context of understanding the business processes and flows and delivering a technical automated solution that meets the needs of the business, can be a very complex endeavor. In addition, we must provide the technical infrastructure and architecture which introduces another type of technical complexity and many of these technical concerns are not directly related to the business. The latter being the how we do it and prior is why we do it. Sometimes it can seem overwhelming, we need a way in which to help distill this business complexity into something more manageable and a way to organize our people, process and technical tools to deliver a solution in a continues way.
Why and How?
Domain-Driven Design strength is its focus on the business domain in the problem space, and its real strength is understand the why. SAFe’s strength is providing a framework for the how. SAFe addresses the complexity of how we build software. SAFe also address the why in its own language as well but I am of opinion that DDD is little stronger in digging in and learning from the business domain experts building the Ubiquitous language and understand the why.
Mike Krieger tells us:
“You can’t start a product simply by building it. You have to know why you’re building it, and you might go down the wrong rabbit hole, waste time, and confuse things. Spending long afternoons with a sketchbook or talking through your ideas with other people can save a year in software development later on.”
Mike Krieger (Brazilian-Amerikan entrepreneur, software engineer and Instagram co-founder.)
Why = functional requirements.
How = non-functional requirements
Let’s delve into the how and why of software development:
Design: Architects and developers create a blueprint for the software, considering requirements, user experience, and technical constraints.
Coding: Developers write source code, translating design into functional instructions for computers.
Testing: Rigorous testing ensures the software works correctly, identifying and fixing any issues.
Debugging: Developers troubleshoot and resolve errors or unexpected behavior.
Maintenance: Ongoing updates, bug fixes, and enhancements keep the software relevant.
2. Why (Purpose of Software Development):
User Needs: Software meets specific user requirements, whether it’s a mobile app, web service, or business tool.
Automation: Software automates tasks, improving efficiency and accuracy.
Innovation: New software drives technological advancements and solves real-world problems.
Competitive Edge: Businesses gain an edge by offering unique software solutions.
Digital Experiences: Software shapes our interactions with technology and the digital world.
In summary, software development combines creativity, engineering, and problem-solving to create functional software that serves user needs and advances technology
The why and how as it pertains to DDD and SAFe:
Let’s examine the purpose and approach of both Domain-Driven Design (DDD) and Scaled Agile Framework (SAFe) and align with the why and how.
1. Purpose:
Domain-Driven Design (DDD) Why: DDD aims to deeply understand the business domain. It creates a rich model that captures processes, rules, and relationships.
Scaled Agile Framework (SAFe) How: SAFe scales Agile practices across large enterprises, connecting domain models to backlogs with a shared language.
2. Approach:
DDD Why: Focuses on ubiquitous language, bounded contexts, and aggregates.
SAFe How: Envisions domain objects collaborating to fulfill system-level scenarios, addressing nonfunctional requirements and enhancing long-term development velocity.
Governance of the process of building software that solves a complex business problem presents a high-level of complexity on its own. SAFe helps bring it all together in a tight framework that provides a language that helps us manage the complex “Business” of building software. As one could argue building software is a business domain on its own with complexity and a language and explains why we need things like SAFe and DDD the assist on our journey. Let’s explore SAFe and then see how Domain-Driven Design fits in.
What’s SAFe Architecture?
SAFe Architecture refers to the architectural practices and principles within the Scaled Agile Framework (SAFe)(9). Here are key points about it:
1. Agile Architecture:
Agile Architecture supports a system’s active, evolutionary design and architecture.
It embraces the DevOps mindset, allowing continuous evolution while meeting current user needs.
Agile architects balance intentional and emergent design, avoiding large-scale redesigns and delays(1).
2. Key Aspects:
Collaboration: Architects work closely with teams, ensuring alignment and addressing technical concerns.
Design Simplicity: Focus on essential design elements, avoiding unnecessary complexity.
Testability, Deployability, and Releaseability: Design for easy testing, deployment, and release.
Domain Modeling: Understand the problem domain and create shared language (ubiquitous language).
Decentralized Innovation: Encourage innovation across teams (2).
3. Roles:
o SAFe defines three architect roles:
o Enterprise Architect: At the portfolio level.
o Solution Architect: For large solutions.
o System Architect: At the essential level (e.g., Agile Release Train).
o These architects collaborate to ensure alignment and address architectural concerns(2).
In summary, SAFe Architecture promotes adaptive design, collaboration, and continuous evolution in large-scale Agile development.(1)
Domain Driven Design:
Domain-Driven Design (DDD) is an approach to software development that focuses on understanding and modeling the problem domain within which a software system operates. Here are the key points about DDD:
1. Collaboration with Domain Experts:
o DDD emphasizes close collaboration with domain experts (such as business analysts, stakeholders, and users).
o Developers work together with these experts to gain deep insights into the intricacies and complexities of the domain.
2. Ubiquitous Language:
o DDD promotes the use of a shared language called the ubiquitous language.
o This language is used consistently across the domain model, system requirements, and code.
o It ensures clear communication between domain experts, users, and developers.
3. Domain Model:
o Developers create a domain model, which is a system of abstractions representing selected aspects of the domain.
o The domain model helps solve problems related to the domain.
o It includes entities (objects with identity) and value objects (immutable objects without identity).
4. Bounded Contexts:
o Instead of having a single unified model, DDD divides a large system into bounded contexts.
o Each bounded context has its own model, tailored to specific subdomains.
o Bounded contexts allow for clear separation and maintainability.
In summary, DDD aims to bridge the gap between technical implementation and business understanding by modeling software based on domain expertise. 5,6
SOLID Principles of Design:
Let’s examine how the SOLID principles of object-oriented design relate to the Scaled Agile Framework (SAFe):
o Definition: A class should have only one reason to change and should handle only one responsibility.
o Role in SAFe: SRP aligns with SAFe’s core value of alignment. By ensuring that each class has a single responsibility, we maintain clarity and focus within our codebase, making it easier to align with business needs1.
2. Open-Closed Principle (OCP):
o Definition: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
o Role in SAFe: OCP supports SAFe’s transparency value. By designing modules that can be extended without altering existing code, we promote transparency in our system’s behavior and evolution1.
3. Liskov Substitution Principle (LSP):
o Definition: Subtypes must be substitutable for their base types without altering the correctness of the program.
o Role in SAFe: LSP contributes to SAFe’s respect for people value. When adhering to LSP, we create consistent, predictable behavior across different parts of our system, respecting the work of other team members1.
4. Interface Segregation Principle (ISP):
o Definition: Clients should not be forced to depend on interfaces they do not use.
o Role in SAFe: ISP aligns with SAFe’s relentless improvement value. By breaking down large interfaces into smaller, focused ones, we improve the flexibility and maintainability of our software, allowing for continuous improvement1.
5. Dependency Inversion Principle (DIP):
o Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions.
o Role in SAFe: DIP reinforces SAFe’s alignment value. By relying on abstractions (such as interfaces) rather than concrete implementations, we ensure better alignment between business requirements and technical design1.
In summary, applying SOLID principles within SAFe helps us create more maintainable, adaptable, and aligned software systems. ??(10).
Domain Driven Design and SAFe:
Let’s explore how Domain-Driven Design (DDD) and SAFe (Scaled Agile Framework) Architecture intersect:
o Agile Architecture is a set of values, practices, and collaborations that support a system’s active, evolutionary design and architecture within the context of Agile development practices.
o It embraces the DevOps mindset, allowing architecture to evolve continuously while meeting current users’ needs.
o Key aspects of Agile architecture include collaboration, design simplicity, and balancing intentional and emergent design.
o It enables designing for testability, deployability, and releaseability, supported by rapid prototyping, domain modeling, and decentralized innovation1.
2. Domain Modeling in SAFe:
o Domain modeling envisions the solution as domain objects collaborating to fulfill system-level scenarios.
o It connects to various backlogs (Team, ART, Solution Train, and Portfolio) and provides a common language for communication.
o Domain models help teams understand the problem space, identify core concepts, and align their work with business needs2.
3. Integration of DDD and SAFe:
o DDD emphasizes understanding the domain and modeling it explicitly in code.
o Once transitioned to a microservices architecture (with the help of domain models), DDD and granular services can work together synergistically.
o This approach provides independence to teams, refined capabilities for services, and decoupled interactions, as seen in many microservices implementations3.
In summary, Agile architecture principles align well with DDD practices, and domain modeling plays a crucial role in connecting business needs to technical solutions within the SAFe framework.(9)
SAFe's Flow and Domain-Driven Designs Role:
In the SAFe (Scaled Agile Framework) flow, Domain-Driven Design (DDD) plays a crucial role in several areas:
o During portfolio planning, understanding the business domain is essential.
o DDD helps identify strategic domains, aligning them with business goals.
o Portfolio Epics and Enablers are influenced by domain knowledge.
领英推荐
2. Value Stream Level (Solution Train):
o DDD informs the creation of Solution Intent, which includes architectural guidance and domain models.
o Solution Architects collaborate with Agile Teams to ensure domain alignment.
o Domain models guide the design of features and capabilities.
3. Program Level (Agile Release Train - ART):
o DDD principles influence the design of ART-level features.
o Teams create domain models for their specific areas.
o ART Architectural Runway includes domain modeling efforts.
4. Team Level:
o Agile Teams apply DDD to design microservices or components.
o They create bounded contexts, aggregate roots, and domain entities.
o Domain events and ubiquitous language enhance communication.
In summary, DDD permeates SAFe at various levels, ensuring alignment between business needs and technical solutions.
Portfolio Level:
Let’s delve into the role of Domain-Driven Design (DDD) at the Portfolio Level within the Scaled Agile Framework (SAFe):
o DDD focuses on describing and modeling entities and their relationships in the problem domain.
o It provides a basis for designing systems that are maintainable, testable, and incrementally developed.
o By identifying domain entities and their interactions, DDD bridges the gap between understanding the problem domain and interpreting requirements.
2. Connecting to Backlogs:
o In SAFe, domain models connect to various backlogs:
o Team Backlog: Teams use domain models to guide their work and align with business needs.
o ART (Agile Release Train) Backlog: ART-level features are influenced by domain understanding.
o Solution Train Backlog: Domain models contribute to Solution Intent, including architectural guidance.
o Portfolio Backlog: Strategic domains and their alignment with business goals are informed by DDD.
3. Common Language and Communication:
o Domain models provide a shared language across the organization.
o They enhance communication between business stakeholders, architects, and development teams.
o By using ubiquitous language (terms from the domain model), everyone gains a consistent understanding.
4. Alternative Design Approaches:
o Connecting domain models to Nonfunctional Requirements (NFRs) helps identify design alternatives.
o When addressing NFRs (e.g., performance, scalability), domain models guide architectural decisions.
5. Agile Design Patterns and Velocity:
o DDD enables organizations to apply Agile design patterns effectively.
o It enhances long-term velocity by ensuring alignment with business needs.
o As the system evolves, updating and improving the domain model is crucial for maintaining system understanding and reducing complexity.
Remember, domain modeling is a powerful tool for reducing system complexity, clarifying requirements, and aligning technical solutions with business goals. (1)(2)
Value Stream Level:
Let’s explore the role of Domain-Driven Design (DDD) at the Value Stream Level (Solution Train) within the Scaled Agile Framework (SAFe):
o The Solution Train is an organizational construct used to build large solutions that require coordination across multiple Agile Release Trains (ARTs) and suppliers.
o These solutions often have high stakes, industry standards, and significant economic impact.
o The Solution Train aligns ARTs and suppliers to a shared mission, ensuring efficient execution of the solution strategy1.
2. Solution Train Engineer (STE):
o The Solution Train Engineer (STE) is a servant leader and coach for the Solution Train.
o The STE facilitates and guides the work of all ARTs and suppliers in the Value Stream.
o They ensure alignment, flow, and effective execution of the shared solution strategy2.
3. Domain Modeling and Solution Train:
o DDD plays a critical role in connecting business needs to technical solutions within the Solution Train.
Here’s how DDD fits in:
o Domain Modeling: Driven by object-oriented design approaches, domain modeling envisions the solution as domain objects collaborating to fulfill system-level scenarios.
o Ubiquitous Language: Domain models provide a common language across ARTs, suppliers, and stakeholders.
o Solution Train Backlog: Domain models connect to the Solution Train Backlog, guiding feature development.
o System Team: The System Team, informed by domain understanding, supports architectural decisions and cross-ART coordination34.
4. Maximizing Flow Across ARTs:
o Each ART within the Solution Train contributes to the solution.
o DDD helps design ARTs to maximize flow across the entire Solution Train.
o By understanding the domain, teams create bounded contexts, aggregate roots, and domain entities.
In summary, DDD ensures a shared understanding of the problem domain, aligns ARTs, and guides solution development within the SAFe Solution Train. 123
Program Level:
Let’s explore the role of Domain-Driven Design (DDD) at the Program Level (Agile Release Train - ART) within the Scaled Agile Framework (SAFe):
o The ART is a long-lived team of Agile teams that collaboratively develops, delivers, and often operates one or more solutions in a value stream.
o It aligns to a shared business and technology mission, eliminating functional silos.
o ARTs exist to realize the promise of value by building and delivering solutions that benefit the customer(5).
2. Cross-Functional Organization:
o ARTs are fully cross-functional, encompassing all roles needed to define, deliver, and operate solutions.
o This self-organizing structure eliminates traditional daily task management and accelerates value flow.
o DDD principles guide the design of ARTs, ensuring alignment with business needs and efficient collaboration.
3. Ubiquitous Language and Solution Intent:
o DDD promotes a shared language (ubiquitous language) across ARTs, suppliers, and stakeholders.
o Domain models inform Solution Intent, including architectural guidance.
o ARTs use this understanding to create features aligned with the problem domain.
4. System Team and Domain Modeling:
o The System Team, informed by domain knowledge, supports architectural decisions and cross-ART coordination.
o DDD concepts—bounded contexts, aggregate roots, and domain entities—guide ART-level feature design.
In summary, DDD enhances ART effectiveness by fostering a common understanding of the problem domain, enabling efficient collaboration, and ensuring value delivery within SAFe’s Program Level.12
Team Level:
At the Team Level within the Scaled Agile Framework (SAFe), Domain-Driven Design (DDD) plays a crucial role in guiding how Agile teams design and develop software. Let’s explore its significance:
o DDD emphasizes understanding the business domain thoroughly.
o Agile teams collaborate with domain experts to identify core concepts, entities, and their relationships.
o This understanding informs the design of features and user stories.
2. Ubiquitous Language:
o DDD promotes a shared language (ubiquitous language) across team members.
o Teams use domain terms consistently, ensuring clarity and alignment.
o The same language appears in code, tests, and conversations.
3. Bounded Contexts and Aggregates:
o Agile teams create bounded contexts—clearly defined boundaries around specific parts of the system.
o Within each bounded context, they design aggregates—clusters of related entities.
o Aggregates maintain consistency and encapsulate business rules.
4. Domain Entities and Events:
o Teams identify domain entities (e.g., customers, orders, products).
o They model these entities as classes or objects in their code.
o Domain events (e.g., “OrderPlaced,” “PaymentReceived”) capture significant changes.
5. Test-Driven Development (TDD):
o DDD aligns well with TDD practices.
o Teams write tests based on domain scenarios before implementing features.
o Tests validate that the code meets business requirements.
6. Continuous Refinement:
o Agile teams continuously refine their domain models.
o As they gain more insights, they adjust the model to reflect the evolving understanding.
o Refactoring code based on domain changes reduces complexity.
In summary, DDD at the Team Level ensures that Agile teams build software that aligns with the business domain, communicates effectively, and maintains a clear understanding of the problem space.
Summary:
We just took a very high level overview of how Domain-Driven Design Combined with Scaled Agile Framework SAFe can provide a powerful approach to understanding and then delivering complex business solutions. Learning never ends so I challenge you to dig deeper and drill into the subjects we discussed today. I recommend you use this Article as outline for a conversation with GitHub Copilot or Microsoft Copilot and learn more and ask different questions and maybe write an article based on your finds. We must learn to use AI to help be more productive and accelerate our learning and development efforts.
Be a learn it ALL!
References:
(1) Agile Scaled Frame work in 5 points(2) SAFe Architecture (3) Architectural Governance (4) What is scaled agile framework? (5) ARTs the Agile Release Train (6) Domain-Driven Design.org (7) Domain-Driven Design Wiki (8) Domain Driven Design Learn.microsoft.com (9) Domain Driven Services Architecture (9) Version 6 Agile Scale Picture (10) Solid Principles of Design