Design approach (Domain driven or Service Driven)

Question

My problem statement is :

I want to write design file management (add, copy, delete etc. operations). There are two approach :

1. Service Driven approach

Write file VO which contains only file attributes. For e.g.

public Class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
}

and separates service for File related operations. For e.g. :

public Class FileService {
        public boolean deleteFile(File file) {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}

2. Domain Driven approach (I might be wrong here.)

Where file VO contains all the attributes plus required operations :

public class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
        public boolean deleteFile() {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}

So what are the pros and cons of both the approach ?

Answer 1

In an object oriented language, putting the logic in the class itself, rather than a service class, is the typical approach (and better IMO). It follows the "tell, don't ask" principle, for example, by telling a File to delete itself, rather than asking some service to delete it. One of the main reasons behind this is to allow for inheritance. For example, if you have a subclass of File and wanted to have it write a log message before it was deleted, that would be difficult to do with a service class because you would need a different service class for every subclass.

In terms of a service-oriented approach, this is typically thought of at a higher level (i.e. a service oriented architecture). Consider a financial stock system, you might have a "buy stock" service and a "sell stock" service. Have a service class that corresponds to individual classes (i.e. a Stock service, which knows how to buy and sell stocks) wouldn't be very object oriented.

You might also have a service layer in your system, which provides integration points with other external services (i.e. a database), but again, I don't think this is what you're talking about here. So, I could stick with the approach of encapsulating the logic in the File class itself.