DDD

Modern web frameworks teach you to take one group of related concepts and split it across multiple places throughout your codebase. Laravel is a robust framework with a big community behind it. Usually it's standard structure is enough for most starting projects.

Building scalable applications, instead, requires a different approach. Have you ever heard from a client to work on controllers or review the models folder? Probably never - they ask you to work on invoicing, clients management or users. These concept groups are called domains.

Developing applications that can perform complex tasks can be a challenging process, and it requires careful planning and design. One approach to managing this complexity is to use a Layered Architecture. This architecture separates the application's code into layers, each with a specific responsibility and purpose. These layers are typically organized in a hierarchy, with higher-level layers depending on lower-level layers.

Modern web frameworks take one group of related concepts and split it across multiple places throughout your codebase. Laravel provides a very clear structure with large variety of tools to make the development easier and faster. Along with the huge community it makes Laravel a great option for most starting projects.

Previously, we explored the fundamental concepts and terminology utilized in Domain Driven Design (DDD), as well as the layers that make up its architecture. In this section, we will examine the artifacts employed to integrate these concepts and construct our application, using PHP as an example.

Domain Driven Design, or DDD, is a software design approach that emphasizes solving business problems and organizing the corresponding logic, rather than focusing on details such as programming languages or infrastructure technologies. The primary goal of DDD is to map real-world systems or processes into software artifacts. In order to enhance our comprehension of the fundamentals of DDD, let's take a closer look at some crucial concepts.

CQRS, short for Command Query Responsibility Segregation, is a simple yet powerful way to split the responsibility for writing and reading data in an application. Instead of having a single service or model method that both changes and retrieves data, you give commands the job of making changes and queries the job of fetching information. This split can make large projects much easier to follow, especially as business rules grow and read and write requirements start to differ.