Action-Domain-Responder can help you keep your architecture clean, have better separation of concerns, and make your code more reusable.
But what actualy is an Action-Domain-Responder pattern?
Doctrine Embeddable is really handy. Using it we can create better and more cohesive Domain Model.
What is a Doctrine Embeddable?
Embeddable let’s you aggregate some properties, that are linked together in some way, into one cohesive class. You may say — well, I can create another entity and create a relation, what is the difference? The difference is, that an Embeddable does not have identity, so it is not an entity. It’s kind of a logical wrapper around properties that together create some concept. At the infrastructure layer these properties end up in the same table row as other entity properties. …
What actually is a “Rich Domain Model”?
Rich Domain Model is what Object Oriented Programming is most suitable for. As we know, OOP helps us, developers, to link behavior (methods) with data (properties) using classes. Unfortunately, often Entities end up as adapters for a database with lots of getters and setters modifying private properties with almost no business logic. It is especially very common when using Active Record pattern, creating MVP product using Rapid Application Development tools and frameworks. And instead of implementing business logic where it would fit the most, in the Model, we end up creating client classes for our domain, where business logic is implemented. Or, especially in web applications, all of the business logic goes directly into a controller, which in my opinion is very harmful. …
At the beginning there was chaos, probably the very first big ball of mud :).
When I started programming, the only thing that used to matter to me was the effect of it. It was fine, as it got the job done and delivered business gain. But as the software I worked on became more complicated, I’ve started to see the downsides of not pre thinking the structure of code and overall software architecture.
When you start learning new framework at the beginning of your software development journey, you don’t think of consequences of coupling anything with anything. You just throw anything you need, anywhere you need. Well, when your app is just a simple CRUD with not complicated (or even none) business logic, it’s fine. But when you are creating an application with a more complicated domain which is something more than just an interface for a database, you should be more concerned about what you are using in which layers. It’s a good practice (for me, at least) to create some structure. …