-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why domain model know about json? #50
Comments
I think it is not strange. It is really helpful using Tags in structure. With tags, we can interpret that file like "Oh, the project of Bogdaan will use a Article data structure. There is fields which describe details of Article and I can see json tags which will be used when binding request or response. Title and Content of Article must be used when request Article in the project. I see how this domain(=Article) works." So in my opinion, tags should be in the domain file. |
@Bogdaan something I read which cleared my doubts about handling validation, you might want check it out: https://medium.com/@apzuk3/input-validation-in-golang-bc24cdec1835 |
My take is the I don't accept or return my domain entities in my delivery layer. Instead delivery specific input and output structs are used and on those I'll use I would also make the case that the validation struct tags do not belong because they don't describe the business rules they are meant to enforce. Are these used during the article draft creation? Are they used when the article is promoted and published? A Validation would be handled in a couple places and for different concerns. Delivery would validate structures, and garbage input checks but nothing business related. Service/Usecases would validate business rules like uniqueness, ownership, relationships, aggregate stuff. Domain entities would have methods to modify internal state and would also do validation. The AWS DynamoDB SDK uses I do have an open mind and a good counter opinion would be considered. |
Hi everyone, thanks for your opinions and recommendations. I agree with @Bogdaan and @stackus to be honest. I've been thinking about this quite a long time ago. I agree to have a separate data structure in Controller and in Repository. But IRL, I never met projects that have a complex marshall method. So, to increase the pace for development, I put the struct tag (JSON and validate) in the domain. But there's a case I forgot which project it is, I have 3 databases, MongoDB, MySQL, AeroSpike. MongoDB has the About this current project in this Github repo, yes, I only put the tag in the domain for the sake of its simplicity LOL. I mean, this is only a simple CRUD. But yeah, I agree with putting the specific tag to its respective layer. JSON and Validate in the controller, BSON, and Dynamodeb tag in the repository. |
I want to add one case that forces me to stop using tags in the domain entity. This is a simple differentiation of access: one user can see specific fields of the domain entity, the second cannot. |
Maybe better to separate this concerns.
The text was updated successfully, but these errors were encountered: