Libro de Carlos Buenosvinos, comprado y añadido aquí para consultas rápidas.
- Chapter 1. Getting Started with Domain-Driven Design
- Chapter 2. Architectural Styles
- Chapter 3. Value Objects
- Chapter 4. Entities
- Chapter 5. Services
- Chapter 6. Domain-Events
- Chapter 7. Modules
- Chapter 8. Aggregates
- Chapter 9. Factories
- Chapter 10. Repositories
- Chapter 11. Application
- Chapter 12. Integrating Bounded Contexts
- Chapter 13. Hexagonal Architecture with PHP
- Chapter 14. Bibliography
So what is all the fuss about? If you've already read books on this topic by Vaughn Vernon and Eric Evans, you're probably familiar with what we're about to say, as we borrow heavily from their definitions and explanations. Domain-Driven Design (DDD), is an approach that helps us succeed in understanding and building software model designs. It provides us with strategic and tactical modeling tools to aid designing high-quality software that meets our business goals.
Read more on the original file...
In order to be able to build complex applications, one of the key requirements is having an architectural design that fits the application's needs. One advantage of Domain-Driven Design is that it's not tied to any particular architecture style. Instead, we're free to choose the architecture that best fits the needs of every Bounded Context inside the Core Domain, which offers a diverse set of architectural choices for every specific Domain problem.
Read more on the original file...
By using the self keyword, we don't The Value Objects are a fundamental building block of Domain-Driven Design, and they're used to model concepts of your Ubiquitous Language in code. A Value Object is not just a thing in your Domain — it measures, quantifies, or describes something. Value Objects can be seen as small, simple objects — such as money or a date range — whose equality is not based on identity, but instead on the content held.
Read more on the original file...
We've talked about the benefits of trying to first model everything in the Domain as a Value Object. But when modeling the Domain, there will probably be situations where you'll find that some concept in the Ubiquitous Language demands a thread of Identity.
Read more on the original file...
You've already seen what Entities and Value Objects are. As basic building blocks, they should contain most of the business logic of any application. However, there are some scenarios where Entities and Value Objects aren't the best solutions. Let's take a look at what Eric Evans has to say about this in his book, Domain-Driven Design: Tackling Complexity in the Heart of Software:
Read more on the original file...
Software Events are things that happened in the system that other components might be interested in knowing about. PHP developers are generally not used to working with Events, which are not a feature in the language. However, it's more common to see how new frameworks and libraries embrace them to provide new ways of decoupling, reusing, and speeding up code.
Read more on the original file...
When you place some classes together in a Module, you are telling the next developer who looks at your design to think about them together. If your model is telling a story, the Modules are chapters. Domain-Driven Design:Tackling Complexity in the Heart of Software -Eric Evans
Read more on the original file...
Aggregates are probably the most difficult building blocks of Domain-Driven Design. They're hard to understand, and they're even harder to properly design. But don't worry; we're here to help you. However, before jumping into Aggregates, there are some key concepts we need to go through first: transactions and concurrency strategies.
Read more on the original file...
Factories are a powerful abstraction. They help decouple the client from the details of how to interact with the Domain. The client doesn't need to know how to build complex objects and Aggregates, so you can use Factories to create whole Aggregates, thereby enforcing their invariants.
Read more on the original file...
In order to interact with a Domain object, you need to hold a reference to it. One way of achieving this is by creation. Alternatively, you can traverse an association. In Object-Oriented programs, objects have links (references) to other objects, which makes them easily traversable, thereby contributing to the expressive power of our models. But here's the catch: you need a mechanism to retrieve the first object, the Aggregate Root.
Read more on the original file...
The Application layer is the area that separates the Domain Model from the clients that query or change its state. Application Services are the building blocks for such a layer. As Vaughn Vernon says: "Application Services are the direct clients of the domain model." You could think about an Application Service as a point of contact between the outside world (HTML forms, API clients, the command line, frameworks, UI, and so on.) and the Domain Model itself. It might help by thinking about the top-level use cases that your system exposes to the world, example: "as guest, I want to register," "as a logged user, I want to purchase a product," and so on.
Read more on the original file...
Every enterprise application is typically composed of several areas in which the company operates. Areas such as billing, inventory, shipping management, catalog, and so on are common examples. The easiest manner in which to manage all these concerns may seem to lean toward a monolithic system. But, you might wonder, does it have to be this way? What if any friction garnered between teams working on these separate areas could be reduced by splitting this big monolithic application into smaller, independent chunks? In this chapter, we'll explore how to do this, so be prepared for insights and heuristics around strategical design.
Read more on the original file...
The following article was posted in php|architect magazine in June 2014 by Carlos Buenosvinos.
Read more on the original file...
Beck, Kent. Test-Driven Development: By Example. Addison-Wesley Professional, 2002.