java - Design approach (Domain driven or Service Driven) -

My problem statement is:

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

1. service-driven approach

Write a file Vo that contains only file attributes, for example.

Public class file {Private Boolean hidden; Private Boolean read; Write private boolean; Public Boolean Hahid () {hidden return; } Public Zero sethold (Boolean hidden) {This hidden = hidden; } Public Boolean is Reid (read; } Public Zero set read (Boolean reading) {this.read = read; } Public Boolean isWrite () {Write Write; } Write public zero set (typing boolean) {this.write = write; }}

and separates the service for file related tasks. For example:

  public class file service {delete public boolean file (file file) {// Add deleted logic. } // In the same way you can copy and copy the file.  

2. Domain induced approach (I may be wrong here.)

Where File VO includes all features and expected operation:

  public class file {Private Boolean hidden; Private Boolean read; Write private boolean; Public Boolean Hahid () {hidden return; } Public Zero sethold (Boolean hidden) {This hidden = hidden; } Public Boolean is Reid (read; } Public Zero set read (Boolean reading) {this.read = read; } Public Boolean isWrite () {Write Write; } Write public zero set (typing boolean) {this.write = write; } Delete the Public Boolean file () {// Delete the add logic. } // In the same way you can copy and copy the file. }  

What are the professional and cons of both approaches?

Without much information about what kind of system it is difficult to demand that you pronounce it For me, the options depend on system boundaries.

If you need to provide an API that comes in the form of a service and accessible to an external consumer, go for solution 1, that is the only way. If you have a library rather than a system whose APIs will be used internally by other applications, go for a rich domain model as solution 2, it is a lot of oo, you have your APIs with service, manager, and utility classes. There is no real reason for this, for which there is no real reason.

But then, without knowing your ultimate goal, it is difficult to say.