Michael Romer - PHP Data Persistence with Doctrine 2 ORM

PHP developers nowadays mostly think and code in an object oriented way. Application functionality is built using classes, objects, methods, inheritance and other techniques of object orientation. In the beginning, OOP has mostly been used for the general technical aspects of application, such as MVC frameworks or logging and mailing libraries. All these components more or less can be used as is in all applications, no matter what domain the application is in: e-commerce, portal or community site. For complex systems and also if aspects such as maintainability and extensibility are important, OOP in the domain specific code also is an advantage. Mainly, every application consists of two different types of code: general technical code and domain specific code. General technical code often is re-usable when built as a library or framework, domain specific code often is too custom to be re-used.

Object oriented domain specific code is characterized by the existence of a so-called domain model. A domain model mainly means:

• Classes and objects represent the main concepts of a domain, the so-called entities (these elements can also be value objects to be precise, but compared to entities, value objects dont have a persistent identity). In an online shop, the main elements would be Customer, Order, Product, Cart and so forth.
• Domain specific classes and objects may have associations between them. Again, in an online shop, an Order usually has at least one Customer that it references as well as one or more references to the Product(s) ordered.
• Domain specific functions are implemented as a part of an entity. In an online shop, a Cart often has a calculateTotalPrice() method to calculate the final price based on the items in cart considering their quantity.
• Functions that span multiple entities usually are implemented in so-called services, simply because they cannot clearly be assigned to one single entity. Again, in an online shop, the Checkout service may take care of lowering the inventory, invoicing, updating the order history, etc. The service deals with several different entities at once.
• Whenever possible, domain specific objects are used instead of generic data containers such as PHP arrays (exceptions prove the rule here).
• Business logic (such as business rules) is implemented within the domain objects of an application, not in e.g. controllers, whenever possible (controllers are used in MVC based frameworks to handle user input).

The main advantage of the domain model lies in having the domain specific code centrally in defined classes and objects supporting maintenance and changes. The possibility of incidentally breaking a function, when changing or extending code, drops. By isolating domain specific code from general technical code, portability is supported. Thats helpful, e.g. when migrating from one application framework to another.

Besides the advantages mentioned above, the domain model also supports teamwork. Often, when building and launching a new software product, besides programmers also business and marketing folks are involved. A domain model can bridge the mental gap between business and IT by unifying the terminology used. This alone makes a Domain model invaluable.

Concrete examples make things easier to understand. Throughout this book, a demo application called Talking will help to put theory into practice. Talking is a (simple) web application allowing users to publish content online. The applications domain model looks like this:

Demo application Talking - Domain Model

A User can write Posts. A Post always only has one author and both entities reference each other. A User can act in one or more Roles. A User references its Roles, but from a given Role, one cannot access the Users in this Role. A User references UserInfo holding the date of registration and the date of de-registration if available. UserInfo references back to a User. A User references ContactData where email and phone number is saved. ContactData does not reference back to its User. A User may reference another User as its life partner. The