ZML
Help on defining aggregates using DDD
I wanted to split it into smaller aggregates, because each of the elements (e.g. Employee, Reservation) has its own rules and life cycle. It seems to me that such an approach would allow for better management of business logic and transactions for each of these elements separately, instead of keeping everything in one aggregate Salon. Besides, I don't know, I'm really getting confused
9 replies
Help on defining aggregates using DDD
I understand the basic principles, but my issue is that in my system, the Administrator can create one (or several) Salons and then add employees, accounts for employees, services, products, clients, schedules, etc. When trying to define aggregates, it seems that I actually have one aggregate, the Salon, from which I can add and manage individual elements. If I were to break this down into several aggregates, I would have, for example, Salon, Employee, Reservation, but then the Salon aggregate would contain other aggregates, and I’m not sure if this is good practice.
9 replies
DbUpdateConcurrencyException
As for the repository, I would like to implement repository patterns to separate database access logic. In the services/controllers, I want to work through the repository. I read a bit about AddAsync and Update, and indeed, in my case, they are unnecessary, but this still doesn't solve my problem. After adding a new employee to the employees collection on the Salon instance, even if I don't use Update, when calling Save on the DbContext, I still get the same error.
9 replies
ASP.NET - Domain Models Validation
Sure, I understand. Maybe I didn't explain how I handled it in my project accurately. Generally, incoming data to the API, such as UserRegisterRequest, is validated using FluentValidation just as you showed above. Then, if the validation is successful, I pass the UserRegisterRequest to the Service where a domain object UserProfile is created, and then it is passed to the repository where it is saved to the database.
The image I attached is indeed the entity, not the DTO. In the DTO, I have nothing but properties and a constructor (unless the constructor is also unnecessary, in which case I'll remove it). As for those methods, in my mind, they were supposed to finally check such basic conditions as whether the passed parameters are not null before creating the entity. Unless this is totally unnecessary and the request validation is sufficient, then in that case I will get rid of those methods.
20 replies