This is what most PHP developer do, most of the time. Most PHP devs don’t like to reuse, they think their case is unique, those who don’t… well, they don’t call themselves php developers, they call themselves drupal devs or wordpress devs or symfony devs or whatever cms/framework dev.

But the real (sarcasm) php dev will create an acl from scratch at every job he have. he will create countless media manager, db layer, session manager, etc. Don’t get me wrong, I think you can’t be a good php developer if you haven’t gone through this stage, but please, for the sake of your coworker sanity, keep you’re “learning process” outside of the workplace and don’t forget that you should stick to “learn-and-throw-away”.

Some bad reason to reinvent the wheel that I hear all the time:

Existing solution does not apply to us

Yeah right, you feel better when you think you are unique, good for you, but unfortunately it’s probably not true. I agree on one thing though, you’re different, everybody is different, that’s why the solution will need to be adapted, but surely not written from scratch.

It’s gonna be faster to create our own solution rather than adapting or learning something else

Yeah right, it’s gonna be faster for the guy doing it this time, but for everybody else trying to use/modify/understand it in the future it’s gonna be a pain in the ass because your solution will be half documented (probably not documented at all) and with no community support. By the time somebody needs help from the original developer, he will probably be working somewhere else, reinventing the wheel again…

There is nothing in the whole universe that remotely resemble what we’re trying to do

Yeah right, again, the “I’m unique” power trip. There’s billion of people on the planet, that have met and fixed billions and billions of problems, a lot of them have written about their solution in books, blogs, code, tweet….

I’ve mentionned DDD in the previous post, this post is me drafting publicly my thought on the design patterns generally associated with it. this is a work in progress.

Even if not doing Domain Driven Development, the design patterns usually used by the DDD people are something that can benefit a lot of project. To start learning more about design pattern, “Patterns of Enterprise Application Architecture” by Martin Fowler ¹ is a must read. If you can’t afford the book, then go steal some money (just kidding) or start by reading the free short summary of each patterns available on the author’s website ².

Domain Models are a representation of the data, they represent nouns in you domain, such as User or Invoice. As the domain model contain the business logic, it should be the most important part of the code, thus it need to be easy to understand, easy to modify and easy to test. That’s why they should have no external requirement, no knowledge of the external world, avoid tight coupling at all cost.

Domain models contains the business logic (verbs), mainly in the Entity and Repository, and some in the service layer (if, and only if the functionality does not apply to an entity in particular, reference others object of the system, and is stateless. (ex1: $shippingService->calculateShippingCost($zipcode). this does not belong in the Cart Entity because of the dependency on external object such as shipping company API).

Entities should be totally standalone, they should not be aware of repository or anything else.

Entities and Repositories does not write directly to a database or web service, a database layer is usually used such as ActiveRecord or DataMapper. But, writing an activeRecord of dataMapper layer is a long and difficult job, and it’s generally a better choice to use an existing one, especially because of the fact that this layer contain no business logic, there is not a big Return On Investment on building our own.

Some part of the application might seems like Entity but are in fact Aggregate. Some object can’t exist by themselves, such as OrderDetails, they are Aggregate that are connected to an Aggregate Root Order. This mean that the Aggregate don’t have a repository and if you want to add a row to an order you need to go thru the Order Entity. ex: $order->addDetail(…)

Domain Driven Design is a development methodology, the term have been coined by Eric Evans ¹.

Domain Driven Design (DDD) being a complete development methodology, that means that you can’t learn DDD simply by reading code sample, and a few things are necessary for his success, such as:

• Developers who understand design patterns
• Access to a Domain Expert and close relationship with the client

The domain expert requirement is a big one, you actually need someone from the domain, ie: if you are in the banking industry, you need a banker to have this role, not a developer or an architect who is a self proclaimed domain expert. DDD involve a lot of communication with the domain expert to define the ubiquitous language ² and integrate them in the domain models. To keep using our banking example, a developer who knows absolutely nothing about banking should learn an awful lot about the domain (banking) just by looking at the code for the domain model.

A DDD team will probably be using a bunch of design pattern such as:

• Domain Model
• Service Layer
• ActiveRecord or DataMapper
• LazyLoad
• Repository & Query Object

But the sole fact of using these patterns does not mean you have a DDD team. I can’t find the orignal source, but apparently ³ Eric Evans almost regrets having mentioned these design pattern in the book because they can lead to that false conclusion that DDD is just ‘using some specific design pattern’ when if fact it is so much more and involve discussion and collaboration with clients and domain experts. We can see the same feeling about design patterns and lack of domain expert expressed in the excellent video “7 Reasons Why DDD projects #FAIL” ⁴ by Greg Young.

DDD is not for everybody, if your app is mainly retrieving data from the database to display with some fancy design, DDD would just be adding a layer of complexity on something really simple, ActiveRecord or DataMapper is probably a better solution for your need. Such an example where DDD is overkill, and e-commerce website for Mom & Pop’s shop, as there is little logic, lots or database reading and some cool graphics… But complex subscription plan and pricing and discount model is a good candidate for DDD.

I won’t go deeper into the world of DDD as I have no experience with it and I’m not currently working on any team that can switch to this methodology easily.

I’ll close this part with a great quote from “DDD Step By Step” ⁵

[...] I view Domain Driven Design firstly as a design methodology, secondly as an architectural style, and lastly as some great software patterns.

More Reading

Stack Overflow have some good links to get you started with DDD

http://stackoverflow.com/questions/493068/best-resources-on-the-web-for-learning-domain-driven-design-ddd-in-depth

(my favorite being the InfoQ miniBook, a quick read that give just enough information to get you interested)