On the Ibuildings techPortal today there's a new post from Robert Raszczynski about domain modeling and how a good knowledge of it can help your application's architecture.

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.

DevShed has posted a series of tutorials talking about different sorts of service layers in PHP applications - seven of them to be exact:

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

In his previous post Vic Cherubini introduced his namespaced DataModler ORM class and showed how to create a basic model to work with user information to the database. In this second part he looks at taking those models and saving their contents to the database.

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 latest blog post Federico Cargnelutti talks about data access layers, data access objects, data mappers and how to implement them in a Zend Framework application.

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.

From Komunitasweb.com today there's new tutorial showing how to use the DataMapper library for the CodeIgniter framework to introduce object relational mapping (ORM) to your application.

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.