CODEWITHSUNDEEP
phpmodelentitydomain-driven-designlaravel-4
rgvcorley
rgvcorley

Reputation: 2923

Confused about model/entity meaning and separation of CRUD and business logic

I am writing an application where most of the legwork is done in the models, the models perform 2 (fairly distinct) groups of tasks:-

  1. CRUD database operations
  2. Create Table, Form and ContentBox objects, populated with with data from the database

Some of the models as a result are quite big, so I have setup the Illuminate Database component from the Laravel framework and I am thinking of using the Eloquent ORM to create models that do the CRUD and then have separate models which generate the Tables and Forms, calling methods in the Eloquent models to get data.

What would be the correct terms for these 2 different 'models' in domain driven design? Do I call the models that do the CRUD entities and the other models models?

I've read a few of the related posts and I understand a model is a model of something in the real world. So for example I've got a model called Invoices which has methods for returning a Form object, for creating a new invoice, and a Table object, for listing all the invoices. But it also has a method for returning a PDF of a single invoice. So this isn't really a model of a single invoice - it has the ability to return data for multiple invoices... is this still a model?

Apologies there are actually 2 questions here, I'm just wondering what the correct terms are, or looking for suggestions to somewhere I can read about this sort of thing, so that I can do something that is considered best practice and will make sense to other programmers.

Thanks in advance.

Update So after reading this it seems to me that what Laravel calls a model (before adding business logic to it) is in fact an entity. So what I'm planning to do is have a folder called Entities with my ORM 'models' in and another folder called Models with the business logic 'models' in - is this common practice?

Upvotes: 2

Views: 1907

Answers (2)

Yugang Zhou
Yugang Zhou

Reputation: 7283

I don't think Table or Form are domain models in your case.

Domain models are reflection of your core business concepts. For example, you can answer whether an Invoice is overdue by call invoice.isOverdue()

On the other hand, Table for listing invoices, outport pdfs are responsible for taking care of presentation concerns.

Presetation components have dependence on Domain objects, but not vice versa. For example, you may list Invoices on a html page or outport Invoices by pdf. But you probably don't want the code looks like this:

public class Invoice {

    Table list() {...}
    File  outport() {....}
    ...add another method for excel maybe? 
}

You may interested in this post for the component's responsibilities.

Upvotes: 2

user1669496
user1669496

Reputation: 33048

It's common practice to setup what are models in laravel in the Models folder. I believe what you are looking for are called repositories which you'd make a folder for, and add it to the autoload section in your composer.json file.

It's considered good practice to have lightweight controllers and models aren't really intended to contain all the extra logic, so having repositories where you'd put all the heavy lifting would help keep your app very organized.

Upvotes: 1

Related Questions