Design approach (domain management or service)

Question

My problem statement:

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

• Service approach

Write a VO file that contains only file attributes. For instance,

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 shares the service for file related operations. 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 (maybe I'm wrong here.)

If the VO file contains all the attributes plus the necessary 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 approaches?

Answer 1

Without a lot of information about which system you want, it's hard to pronounce. For me, the choice depends on the boundaries of the system.

If you need to offer an API that opens as a service and is accessible to an external consumer, go to solution 1, this is the only way. If your system is more likely a library, the API of which will be used inside other applications, go to the model with a rich domain, as in solution 2, this is much more OO. You do not want to inflate your API with utility, manager, and utility classes for which there is no real reason.

But then again, not knowing the ultimate goal, it's hard to say.

Answer 2

In an object-oriented language, the typical approach (and the best IMO) is to place the logic in the class itself, and not in the service class. It follows the principle of "say, do not ask", for example, informing the File about the removal of itself, and not ask any service to delete it. One of the main reasons for this is permission to inherit. For example, if you have a subclass of File and you want it to write a log message before deleting it, this would be difficult to do with the service class, because for each subclass you would need a different service class.

As for the service-oriented approach, this is usually considered at a higher level (that is, in a service-oriented architecture). Consider a financial reserve system, you may have a buy shares service and a sell shares service. Has a service class corresponding to individual classes (i.e., a stock service that knows how to buy and sell shares) will not be object oriented.

Your system may also have a service level that provides integration points with other external services (i.e. the database), but again, I don’t think this is what you are talking about. That way, I could take the approach to encapsulating logic in the File class itself.