Design approach (Domain driven or Service Driven)

Question

Hi All,

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.
}

1. 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.

Answer 2

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.