I have a nestjs application using DDD.
I have following folders:
Domain
Application
Infraestructure
I have the use case of scraping information from youtube channels. DDD is clear to me if I end up saving things in the database. But if I am only scraping? once the scraping is finished, then I would have the use case of saving in the database
Application
use-cases
scrapChannels.useCase.ts -> instanciates the youtubeLogsRepository interface in the constructor
Domain
entities
ports
repositories
youtubeLogs.repository.ts -> interface with getYoutubeLogs() method
Infraestructure
adapters
presentation / http / controllers
repositories
youtube-logs
youtubeLogsScraper.repository.ts -> here the logic to scrap
I placed the logic to scrap in infraestructure, but not sure if it should be in the domain. Also not sure if it should be under repository, since it's not touching the db. If not, then where it should go?
Related
I am building an ecommerce website for a project for my portfolio, and I wanted to know where the calculations should be done for the cart.
Normally I use react and I create a model folder, route folder and a controller folder but the way I was taught Angular it seems like the services acts like the routes and the actual calls to the database are done in the node server file which I am sure I could separate into a separate controller file. My question is where should the calculations for the cart be done before I send the order to the database? I thought about doing it in the cart component before the order is place or should it be done in the services or in the backend in the controller? I am just trying to figure out what is the standard
When writing an Angular app, I think it is important to adhere to the following principles that:
Components - should have a single responsibility for simple view logic only, shouldn't reach out to the server, and shouldn't do complex calculations and/or logic that is not related to the view.
Services - should have a single responsibility for (reusable/shared) and complex logic, to do outbound communication and reach out to the server, and to act as data stores (using BehaviorSubjects).
Therefore, if your calculations are needed to update the view of the cart, I would vote that these calculations need to be made at the component. If your calculations are needed to update the items or the request to be sent to the server, they need to be made at the service.
Remember, the component "shouldn't know" how the data comes to it or how it is manipulated or sent to the server. The component should only know, given any data - how to present it in the view, and shouldn't "worry about" how that data came to it. Similarly, the component shouldn't know how the data is calculated before being sent to the server, and this would fall within the responsibility of the service that works with and processes the cart data and builds the request to the server.
However, you have to always consider the security of your app, and if a malicious data modification at the client side can affect your cart. If such caculations affect the app's security - they should at least be validated at the server if not fully delegated to it.
I don't know the calculation you need exactly, but since it is an e-commerce website I assume it is simple math such as the total payment amount of checkout.
The main role of the server is communicating to the database. If a task does not involve interacting with data, you can do the calculations on the client-side. Leaving details on client-side allows you to have access to details of your formula, and reduce the communication time between client and server.
Imagine I have an angular project as a front-end which communicates with some other projects which are restful services.
In some pages I need to fetch some data from different restful services,
Is that okay to request any restful service individually in angular?
Or call one restful service which itself call other restful services in back-end?
Or I have to call one restful service but add other entities to this DbContext which I need here just to query?
It depends on what you're doing, but I would say mostly it's OK to do this. This is an established microservices pattern called "Composite UI". See this for details: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
If your microservices are using the CQRS pattern, (while still not wrong) you may be missing an opportunity to compose a view-specific "view model". However, if you're composing\showing data from multiple domains I would say that it's still better to just call multiple microservices to retrieve the data you need.
The only problem you may be introducing if you're not careful, is introducing projection logic (which is not THAT bad) or business logic (very very bad) in your client code if you're doing any processing on the data you receive in order to display it. Composite UI is meant to server a UI with clearly separated sections.
I've never had anything to do with AngularJS or any frontend technologies, so it's hard for me to grasp. I have a jHipster project that I need to customize and turn into a useful thing. How it looks doesn't matter for now, it needs to work. I watched the "jHipster in 20 minutes" video and even read the minibook, but these didn't help me understand how to deal with the generated files.
I need some guidelines and explanation on how files like entities/entity1/entity1.controller.js, entity1.service.js and entity1.state.js are dependent on each other (and on Java Spring #Services/#Controllers/ Spring Data entities in general). What's the procedure to add new functionalities (views, dialogs)?
In short.
Controller: decorator of the entity
Entity: is what backend(spring boot) gives you
Service: used to make calls to the backend to get the entity data.
State: -> uses the service -> uses the "Backend" to get Entity data
and sets the Entity on the Controller
I am developing a Nodejs application and my database is Postgres and I am using Sequelize as my ORM because of its excellent support for migrations.
I am on the lookout for a good REST API generator based on the schema I have defined. There are two main hurdles I am facing and they are that the generators don't do a good job of creating association API routes and lack of ACL support.
On the associations front, my schema has multiple levels of association i.e. for example..
Student.hasMany(Courses);
Courses.hasMany(Subjects);
So ideally the generated REST API should be something like
/student/:student_id/course/:course_id/subject/:subjectId
I found a few projects that are doing this, but are incomplete.
https://github.com/sequelize/sequelize-restful - is good but does not have ACL support
https://www.npmjs.org/package/restizr - is in alpha stage and does not generate API routes for associations.
Is there any module that supports this?
What you were doing here is writing a webservice without a domain model. https://en.wikipedia.org/wiki/Anemic_domain_model Ofc. you have every right to do it, but I wonder if you really understood what a webservice means. https://stackoverflow.com/a/1530607/607033 It is not a database with CRUD HTTP interface normally, though nowadays it is popular doing something this way and call it REST. A response to a REST HTTP request is a viewmodel https://softwareengineering.stackexchange.com/a/425001/65755 and it contains not just data, but a lot of metadata and hyperlinks. A REST API is a special type of webservice with many constraints. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf http://www.markus-lanthaler.com/research/hydra-a-vocabulary-for-hypermedia-driven-web-apis.pdf Your ORM is used 2 layers deeper in the data layer and it has nothing to do with the presentation layer where your REST API should be. I really wonder why people are making applications, which are doing nothing except serving data directly from the database and use the most inconvenient technology to do it. I guess there are databases nowadays with ACL and REST API support, so all you need is just using them. https://learn.microsoft.com/en-us/rest/api/sql/ Or there was something for PgSQL and Nodejs too around the time you asked this. https://github.com/QBisConsult/psql-api
I am new to DDD but I am trying to implement it in my Project - I have a service which is setup following the DDD principles - Application / Model / Repository - The Clients of the Service want to get back a DTO class (which also contains a Error Collection as one of its members) . Questions is how do I populate the Error Collection of the result DTO. Can the Error DTO be passed from the Application/Service Layer to Model/Service layer and populated there – Can someone point me to some example of these kinds of scenarios Currently I am bubbling up all the errors that I am getting back to the Application Service and populating it there like I said I am struggling.
As a general rule try not to copy code (classes, methods, interfaces). If you really have to use DTOs create them as late as possible in the process so that if you remove them you should still be able to use the system in another way.
I would have something like this:
Model
Domain classes
Error class
Model/Service (has reference to Model)
Application/Service (has reference to Model and Model/Service)
Domain DTOs
Error DTO
Also a question do you really need two Service Layers? Avoid Anemic Domain Model