Libene Fernandes’s Reviews > Domain-Driven Design in PHP > Status Update

A Repository “mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.”

...Data Transformers might be a better approach on specific cases. These are just black boxes with Domain concepts (Aggregates, Entities, etc.) as inputs and read-only representations (XML, JSON, CSV, etc.) as output.

...DTOs are a clean and simple solution that could be passed to template engines for different representations, but this might complicate the logic of this last step of data transformation, as the logic for such templates could become a problem to maintain, test, and understand...

Consider a similar case for a blog. We might expose our potential as writers in HTML to the world, but some people will be interested in consuming our articles through RSS. The use cases — Application Services — remain the same. The representation doesn’t...

A good software architecture allows decisions about frameworks, databases, web- servers, and other environmental issues and tools, to be deferred and delayed. A good architecture emphasizes the use-cases and decouples them from peripheral concerns.

Modules are a way to communicate, as they provide us with insights about how the Domain Model works internally, along with helping us increase the cohesion and decrease the coupling between the concepts. Modules are not just a way to group related concepts in the model, but also a way to express part of the design of the model.

The essence of a Domain Event is that you use it to capture things that can trigger a change to the state of the application you’re developing or to another application in your Domain that’s interested in those changes. These Event objects are then processed to cause changes to the system and stored to provide an audit log.

When developing a single application, Events come in handy for decoupling components. When developing a whole Domain in a distributed way, Events are very useful for decoupling each service or application that plays a role in the Domain. The key points are the same, but on a different scale.

The way to avoid falling into an Anemic Domain Model is to, when starting a new project or feature, think of the behavior first. Databases, ORMs, and so on are just implementation details, and we should strive to push the decision to use these tools as late in the development process as we can. In doing so, we can focus on the one true attribute that matters: the behavior.

...Typically, when starting a new project or feature, it’s easy to fall into the trap of modeling the data first. This commonly includes thinking that each database table has a direct one-to-one object form representation. However, this thinking may or may not be the exact case all the time.