Dhairya-Khara / Intentful

Apache License 2.0
2 stars 3 forks source link

Apply Clean Architecture #58

Closed chenikabukes closed 1 year ago

chenikabukes commented 1 year ago

Applying clean architecture is an essential part of CSC207, hence it's our priority to implement clean architecture principles into our project.

aidanmrli commented 1 year ago

Aidan Wed 16 Nov: Have separate folder for entities, use case interactors, and controllers (routing).

Possibly make a data persistence layer (data access layer) for database logic. Idea: isolate upper layers from specific db technology. if we change the db, only need to change files in this layer. (prev comment from TAs: You have your DAO in the same place as your controller - separate these two)

Questions to ask:

Q1. Do we need input/output boundary or can we access the use case interactor from the controller?

Q2. is user.save() fine in use case interactor? (technically, save is interacting with the db directly. On the other hand, our entities are Mongoose Schema, and save is an abstraction provided by Mongoose, so save is technically from the entities)

BerkeAltiparmak commented 1 year ago

Current approach: Controllers -> Use Case Interactors -> Controller/Presenter Need to confirm if we need this approach instead: DAO -> Controllers -> Input Boundary -> Use Case Interactors -> Output Boundary -> Controller/Presenter -> DAO

Overall we did a great job this week in having a cleaner architecture. Let's go guys!

aidanmrli commented 1 year ago

Observer pattern addeventlistener in the controller. setinputboundary, setoutputboundary in the controller

aidanmrli commented 1 year ago

Comments after Thurs 17 Nov TLI session: we do not necessarily need input/output boundary as the endpoints in the controllers are literally the input/output boundaries.

We should add comments to the entities schema file - technically, because we are so reliant on MongoDB and the mongoose schema wrapper, this isn't clean. However, because this is a MERN app, it is focused on MongoDB. Ideally, we would create an abstract class or something for an entity and implement the class in Mongo in a data persistence layer, possibly not even using Mongoose schema. However, this is too much work and it's not feasible given the scope of our project (need to alter every file in the backend).

aidanmrli commented 1 year ago

Feedback after Milestone 4:

Discussion after Thursday Dec 1 TLI Session There are some challenges storing a Mongoose schema inside a Mongoose schema. Since our Transcript already follows a consistent data format, and we have a regulated data structure representing each transcript, we think that it is potentially not worth revamping our whole project at this stage. Our Transcript representation (while not an explicit entity) is an object that has very consistent attributes (the raw file, and the intents), and so we believe it is scalable.