News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Mathias Verraes:
Resolving Feature Envy in the Domain
August 12, 2014 @ 11:55:24

Mathias Verraes has a new post today about something he calls "feature envy" in the domain, related to this code smell (based on a definition from Martin Fowler).

Benjamin Eberlei did a really nice job of explaining refactoring the Feature Envy code smell on his blog. I wrote a comment because I felt the example could be taken one step further. You should read the original post. Below are Benjamin's code examples (for reference), followed by a repost of my comment.

The "smell" is defined as "a method that seems more interested in a class other than the one it's in". Mathias includes the code examples from the other post showing a datetime calculation and how it could be abstracted out to another class and method. He talks about the migration and how it relates to the "Whole Value" pattern and integrating some of the logic into a factory, generating a "reporting period" instance. He finishes the post with a brief look at an application of domain-driven design concepts to the problem, suggesting that the reporting be even more abstracted from the datetime data and using the "reporting period" object instead.

0 comments voice your opinion now!
feature envy whole value designpattern class object abstraction domaindriven


Mathias Verraes:
DRY is about Knowledge
August 04, 2014 @ 10:51:50

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

"Don't Repeat Yourself" was never about code. It's about knowledge. It's about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

0 comments voice your opinion now!
dry dontrepeatyourself principle knowledge domaindriven design business goal


Mathias Verraes:
Why Domain-Driven Design Matters
May 21, 2014 @ 09:06:36

Mathias Verraes has a new post to his site sharing a set of slides from his presentation on why domain driven design matters in software development projects.

In the software industry, the life expectancy of ideas, methodologies, and technologies, is extremely short. And yet, after ten years, Domain-Driven Design is still growing bigger. [...] In this session, we'll discuss what DDD is: from design patterns and modelling techniques, to the more philosophical ideas about how we deal with complexity. We explore why it has made such a profound impact, and how to decide whether it's right for your project. We'll have lots of room for open discussion, to make sure all your questions are answered.

It was presented at Akamon in Barcelona, Spain and the post includes his full set of slides from Speakerdeck.

0 comments voice your opinion now!
presentation domaindriven design slides akamon

Handling Collections of Aggregate Roots - the Repository Pattern
May 17, 2012 @ 08:44:37

On today they have a new tutorial focusing on using the Repository (a part of the domain driven design architecture) to enhance your model's current functionality.

Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model's language, as it's intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

0 comments voice your opinion now!
repository pattern domaindriven architecture tutorial mapper

Tibo Beijen's Blog:
DDD using Doctrine 2 A case study
June 28, 2011 @ 10:54:15

In a new post to his blog Tibo Beijen presents a case study about doing Domain Driven Design in an application using Doctrine2 to work with objects and your database.

Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

0 comments voice your opinion now!
doctrine2 domaindriven design ddd casestudy example

Federico Cargnelutti's Blog:
Domain-Driven Design with Zend Framework
March 24, 2009 @ 10:23:20

Federico Cargnelutti has posted the latest article in his "domain-driven design" series using the Zend Framework. This time he focuses on putting some of his ideas into practice.

Some of the Domain-driven design concepts explained in my previous posts are applied in this sample application. I'm also going to use the Zend Framework infrastructure to speed up some development tasks.

His example sets up a domain layer to interface user information for the system from a centralized repository. On top of that he builds his model extended from an abstract class called Zf_Domain_Entity. He also sets up a User collection, a User DAO and the user repository

0 comments voice your opinion now!
domaindrivendesign domaindriven zendframework application

Community Events

Don't see your event here?
Let us know!

api zendserver package deployment library podcast laravel tips series interview release introduction install language list opinion framework community symfony update

All content copyright, 2014 :: - Powered by the Solar PHP Framework