Code insights

[lucasmafra]

Hi @davicorreiajr,

Here are some code insights you might find useful:

1) You don't have to await for a promise to resolve when you're returning the result of that promise in an async function.

For instance, you could replace the snippet above

async getAll(): Promise<Bleus[]> {
    return await this.repository.find();
  }

...for the equivalent:

async getAll(): Promise<Bleus[]> {
    return this.repository.find();
  }

2) In many classes you're using the @Service annotation from typedi. I don't get why you're doing that in your code. It doesn't look like you're injecting any dependencies in your classes through the dependency injection. Typedi is not taking control over any component lifecycle. Also, even if typedi is doing something for you, I don't see why you would want to apply the @Service decorator in you your use case classes. Do you need them to be single instance across all your application? Or you just need the classes that access the database (in this case, the Repository) to be single instance?

3) It seems that you're taking some Clean Architecture/Ports and Adapters approach in your code. IMHO, the Entity classes should reside in your domain module, not in your data layer. In Uncle Bob Clean Architecture proposal, the Entities are the most pure classes in your application: they encapsule the enterprise/application business rules.

4) You have some dependencies in your package.json that could be listed as devDependencies instead. This is important to keep you final bundle minimal. Here are some dependencies you could restrict for development only:

    "@types/multer": "^1.3.7",
    "@types/node": "^10.12.18",    
    "errorhandler": "^1.5.0",
    "reflect-metadata": "^0.1.12",
    "typescript": "^3.2.2"

[davicorreiajr]

Thank you so much!

About 3., how should I structure my domain folder then? Something like this?

domain\
|_ use-case\
|_ entity\

[lucasmafra]

That looks closer to Uncle's Bob proposal.

But the folder you put your classes in is not as important as the role they play in your application. The concept of Entity he talks about is taken from Eric Evans' Domain Driven Design. In this concept, the Entity class encapsulates methods with pure business rules. This is not trivial and in many applications I've seen the entities endup becoming just POJOs with no encapsulated behavior, just holding data that comes from some data source (e.g a class that represents a database table).

For instance, imagine that you're building a system for, let's say, a congress of Engineering in your college. At some point you gonna have to deal with lectures and reservations as they are part of your domain modeling. If you're going for the Entity approach, you should add a rule in your Lecture entity that explicit tells the outside world whether there's room for more inscriptions. On the other hand, if you're not doing that sort of Entity modeling, I would expect to see that business rule somewhere else (e.g your use cases).