Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

If you're looking for an approachable guide that teaches you how to implement an easily-customizable service layer in PHP, then take a peek at this article series. In a step-by-step fashion, it walks you through the development of a sample web application, which uses a service to perform CRUD operations on a domain model composed of a few user entities.

Service layer types covered in the series are:

• Working with database entities
• Data Mappers
• Database adapters
• Handling Entity Collections
• User Services
• Dependency Injections
• Modeling Domain Objects

After you have created your Models, it's time to save them to a datastore. DataModeler requires you to use PDO as the abstraction layer as it makes use of prepared statements and database specific extensions.

He bases it all on PDO object - created and pushed in via dependency injection. The model then uses that object and executes a "save()" containing the data created in the model request. He also talks about "dumb loads", a feature that lets the modeler think it was loaded without having to know anything more than just the object's ID number.

In his example code he creates a few new directories in his basic application layout under the "lib" directory to contain the files for the mapper, data access layer and data objects. He uses s simple "user" table with first and last names and an ID to help identify the row.

The User model, mapper and data access object work together to make a simple "getUser" method as easy as creating a new Project_DataMapper_User object and setting up the entity before doing the fetch with a "get" call.

If you familiar with CodeIgniter, then you have realized by now that you can't have relationship manager. Yes, CodeIgniter doesn't have built-in ORM. But there are several projects such as IgnitedRecord and DataMapper that will help you manage relationship between your models.

The post walks you through the installation of the tool, creating some sample data to work with and creating a full model, controller and view as an example.