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

Without much information about what kind of system your are desigining it’s hard to pronounce. To me, the choice depend on the system boundaries.

If you need to offer an API that is exposed as a service and accessible to external consumer, go for solution 1, that’s the only way. If you system is rather an library whose API will be used internally by other applications, go for a rich domain model as in solution 2, it’s a lot more OO. You don’t want to bloat your API with service-, manager-, and utility classes for which no real reason exist.

But again, without knowing your final goal, it’s hard to say.