From 2002 to 2004 I went to QUT and studied Information Technology majoring in Software Development and Data Comms, during this time I mostly worked with Java, in java we modeled objects off the real world entities we were working with such as Customers, invoices and invoice items, these objects are joined through references between objects and collections. I have recently come to learn that this is what martin Fowler refers to as the domain model well at least a core principle of. In my first job I went to work for a company that wanted a windows client application for weighing and inducting cattle, I had only ever made java web apps and some really simple swing apps, however I needed some better tools for the job at hand being the only IT guy and developer looking after a multi million dollar operation with a couple of hundred staff, (there were only around 25 actually in the office so it want really that impressive an undertaking) I looked around at what applications were available I came across a free offer to try out the Visual studio 2005 beta 2, so I took that up. The IDE was very impressive, I got stuck in and did some walk throughs setting up a data source to a Sql server, and then dragging that data source onto a form, this was pretty cool, but the data there really wasn't exactly what I wanted, there was data in other tables I needed to get at and display, so I grabbed the Id and went off again to the database to grab some more info. This seemed very inefficient to me especially if I had to traverse across multiple tables. (Fowler refers to this as the table model) But it seemed a common way to do things, looking at guidance online and in forums all pointed in the direction that using typed data sets is the way to go. So I built the system this way it was difficult to build, difficult to maintain. I longed for my domain objects again where the logic and validation was neatly contained in an object. This is where my journey began three years ago.

Just so you know what I am talking about when I refer to Table model and Domain model, Jimmy Nilssons book "Applying Domain Driven Design and Patterns"[2006] he summarized Martin Fowler's take on defining Patterns for Dealing with the main logic:

Martin Fowler discusses three ways of structuring the main logic in application architecture in his book Patterns of Enterprise Application Architecture [Fowler PoEAA]. Those are Transaction Script, Table Module, and Domain Model.
Transaction Script is similar to batch programs in that all functionality is described from start till end in a method. Transaction Script is very simple and useful for simple problems, but breaks down when used for dealing with high complexity. Duplication will be hard to avoid. Still, very many very large systems are built this way. Been there, done that, and I've seen the evidence of duplication even though we tried hard to reduce it. It crops up.
Table Module encapsulates a Recordset [Fowler PoEAA], and then you call methods on the Table Module for getting information about that customer with id 42. To get the name, you call a method and send id 42 as a parameter. The Table Module uses a Recordset internally for answering the request. This certainly has its strengths, especially in environments when you have decent implementations for the Recordset pattern. One problem, though, is that it also has a tendency to introduce duplication between different Table Modules. Another drawback is that you typically can't use polymorphistic solutions to problems because the consumer won't see the object identities at all, only value-based identities. It's a bit like using the relational model instead of the object-oriented model.
Domain Model instead uses object orientation for describing the model as close to the chosen abstractions of the domain as possible. It shines when dealing with complexity, both because it makes usage of the full power of object orientation possible and because it is easier to be true to the domain. Usage of the Domain Model pattern isn't without problems, of course. A typical one is the steep learning curve for being able to use it effectively.