DDD não é sobre arquitetura - O que é Domain-Driven Design | Dias de Dev

Summary

In this video, Vinícius Dias discusses Domain-Driven Design (DDD) and addresses common misconceptions, especially regarding the organization of folders and software architecture. He clarifies that DDD is not about folder structures or a specific architecture pattern but a philosophy that ensures software aligns with real-world business rules. He introduces DDD's principles, such as ubiquitous language and bounded contexts, explaining how they help bridge communication between technical and non-technical teams. Vinícius also emphasizes that DDD encourages software to reflect the complexities of a business domain, not just automate tasks.

Takeaways

• 😀 DDD is not a folder structure or architectural pattern, but a software development philosophy that focuses on modeling software based on real-world business domains.
• 😀 Many junior developers struggle with understanding DDD’s folder structure, but the organization of code is not the essence of DDD.
• 😀 DDD encourages aligning software development directly with the business domain it aims to automate, ensuring that the software mirrors real-world processes.
• 😀 DDD is not about following strict patterns for architecture, but more about how to bring business logic into the code and make it reflect the domain.
• 😀 The term 'Domain-Driven Design' was introduced in Eric Evans' book, where he explains the concept of 'attacking complexity at the heart of the software' by focusing on business rules.
• 😀 DDD uses both **strategic patterns** (such as ubiquitous language) and **tactical patterns** (like the repository pattern) to structure business logic and code.
• 😀 **Strategic patterns** involve understanding the business domain and creating a shared vocabulary for both technical and non-technical teams.
• 😀 **Tactical patterns** focus on how to structure the code to separate domain logic from infrastructure and ensure the domain is not affected by external complexities.
• 😀 DDD often involves separating the domain from infrastructure using a layered architecture, where different layers handle specific concerns (e.g., application, domain, infrastructure).
• 😀 The goal of DDD is to facilitate communication between technical and non-technical stakeholders, ensuring that both sides understand the business domain clearly and effectively.
• 😀 DDD should not be confused with any specific architecture style. Instead, it’s a philosophy that guides how software can be structured to represent real-world business processes.

Q & A

What is Domain-Driven Design (DDD)?

Domain-Driven Design (DDD) is a software development philosophy that emphasizes aligning the software with the business domain it aims to automate. It focuses on bringing real-world complexities into the software in an idealized form and ensuring the code reflects the business rules and processes.

What is not DDD according to the video?

DDD is not an architectural pattern nor a way to organize your project’s directories. It's also not a standard for how your code should be structured, and any confusion regarding the folder structure in a project is not necessarily related to DDD.

How did Vinícius Dias get the idea to create the video on DDD?

Vinícius Dias was inspired by questions he saw on Twitter, where people, particularly those newer to software architecture, were struggling to understand the folder structure of DDD in their projects.

What is the main goal of DDD when developing software?

The main goal of DDD is to ensure that the software development process is closely aligned with the business domain. This means automating business processes in a way that reflects real-world rules and operations.

What is an example of how DDD helps in a business scenario, like salary increases?

In a salary increase scenario, DDD ensures that the software system reflects the complex business rules related to salary increases, rather than just providing a simple interface for updating a salary in a database.

What does the term 'Ubiquitous Language' mean in DDD?

Ubiquitous Language refers to the practice of using the same terminology throughout the software, ensuring that both technical and non-technical stakeholders are on the same page. For example, the term 'student' might be used in both the academic and financial contexts, but each department uses the term in a way that makes sense for their part of the system.

What is the difference between strategic and tactical patterns in DDD?

Strategic patterns in DDD involve high-level guidelines for understanding and modeling the business domain, like mapping business rules and identifying different contexts. Tactical patterns, on the other hand, are focused on actual coding practices, such as using repositories to separate data handling from business logic.

What is the role of 'Bounded Contexts' in DDD?

Bounded Contexts are clear boundaries within the software where certain terms and concepts have specific meanings. For example, a 'student' in an academic context may be different from a 'customer' in a financial context. Each of these terms should be handled separately to avoid confusion.

Does DDD prescribe a specific folder structure for organizing code?

No, DDD does not prescribe a specific folder structure. While some people may associate DDD with certain organizational structures, such as layered architectures, the methodology itself is more focused on ensuring the software mirrors the business domain rather than enforcing a specific directory layout.

What are some common architectural patterns that can be used alongside DDD?

Common architectural patterns that align well with DDD include Layered Architecture, Hexagonal Architecture, and Clean Architecture. These patterns help isolate the core business logic from external concerns like the user interface or infrastructure.