-
Notifications
You must be signed in to change notification settings - Fork 61
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
Clarification on Model / Service business logic ownership #1
Comments
This makes sense. I prefer to phrase the same thing in the following way. Model layer must own the information i) Simple information from data fields e.g. Service / business logic layer must take care of transactions and coordination to make a certain thing happen e.g. save the Order and send an email to the customer. To achieve this the service layer uses the information coming from the model layer. I have seen previously methods like |
So to help clear up the language here:
I think the term "business logic" is too abstract for this guide, so I think we should drop it. |
Agree with @phalt - "business logic" is too abstract for this. It becomes loaded for meaningful discussion. I have a preference for creating boundaries around natural sets of entities. A timely example is Where these sets of entities interact, this could be done through a service layer. This layer would be responsible for co-ordination and doing data munging to comply with the model layer's api (there's quite a bit of this). |
Also, without going crazy, I think we should just experiment. In combination with best practice, we'll find something that suits us. |
I've had people asking for more clarification on what business logic should live where. "Should I put this method in the model or the service layer?"
A common anti-pattern is the anemic data model, where Models are so basic they basically set and get data. I would like to avoid that, and I didn't plan for DADs to promote that. My main goal in the separation was drawing a line between presentation/service-level functionality and data storage functionality
The current DAD (Django Api Domain) version rules that
Models
should not have any complex business logic, but they can do simple thing like provide computed values, like so:The
Services
should handle more complex business logic across multiple Models, or multiple domains.I think we need to add some more examples of what type of logic should live where, and I want to allow suggestions from the community.
Here is my current feeling on the matter:
Models
Models should handle the following business logic:
Services
Services should be putting together service-level or presentation logic that might spread across the whole domain or many domains. For example:
Is this level of clarification sufficient?
Should the bar be moved more in one direction or the other?
Feedback please.
The text was updated successfully, but these errors were encountered: