Timeline for How accurate is "Business logic should be in a service, not in a model"?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 14, 2022 at 15:24 | comment | added | Álvaro García | @Andy the new versions of EF Core adapts DDD very good, the domain classes doesn't need to mach 1:1 with the tables of the database. With fluent API, shadow properties and another techniques, the domain defines the classes, and it is entity framework who maps the classes from the domain to the tables of the database. Also, EF allows to map value objects. Yo can see some documentation here: docs.microsoft.com/en-us/dotnet/architecture/microservices/… | |
| Sep 14, 2022 at 14:32 | comment | added | Andy | @ÁlvaroGarcía This is how I suggest structuring things; the domain is built on the Csla framework: github.com/MarimerLLC/csla/blob/main/Samples/ProjectTracker/… | |
| Sep 14, 2022 at 14:28 | comment | added | Andy | @ÁlvaroGarcía Also, having the application layer know about the repository ends in leaky abstractions; the domain should know the "units of work," the application shouldn't. I | |
| Sep 14, 2022 at 14:25 | comment | added | Andy | @ÁlvaroGarcía Yeah, that example looks like its mapping a business object directly to the DB with EntityFramework... which breaks encapsulation. Unless somethings changed with EF, you end up having to have your domain model match the DB table structure, and then you will use the same Order object everywhere, even in use cases were certain properties aren't needed/shouldn't be editable, it will be, because the property is also a field on the table. Only in the most trivial apps have I ever found that to be maintainable. | |
| Sep 7, 2022 at 17:25 | comment | added | Álvaro García | @Andy I was reading seeing this example in: github.com/dotnet-architecture/eShopOnContainers/blob/…. In this, it goes in my way, the domain only do the core of the logic, when to get the data to update and when to persist the modifications done by the domain, it is responsability of the application layer, in this case, a handler in an ASP proyect. | |
| Sep 7, 2022 at 16:56 | comment | added | Andy | @ÁlvaroGarcía So stick to those interfaces. Breaking encapsulation means you need to expose things you normally wouldn't, and those things then typically end up getting used in your UI layer, making refactoring the DOs later harder. It also means you lose access control (the data layer has to put data into the DO to populate it, for example). | |
| Sep 7, 2022 at 16:55 | comment | added | Andy | @ÁlvaroGarcía I think the domain objects need to handler their own persistence. The choices are let it do so and it "knows" more than it should, or have some other class handle it which would require breaking encapsulation. IMO breaking encapsulation is way worse than the DO knowing about the persistence layer. You tell your DO to "Save" and it figures out what exactly that means (insert, update, delete from DB). How that's done is all an internal implemenation detail, and you can mock away using DB abstractions (in .Net, IDbConnection, IDBCommand, etc.) | |
| Aug 2, 2022 at 17:52 | comment | added | Álvaro García | @Andy I am agree that it is better in the UI to use the domain classes, but I have the doubt if the domain classes has to be responsible to persist the information or only do the business logic? Because sometimes I read domain classes should to be implemented thinking that is only in memory representation, so I understand that it should not concern about persistance. | |
| Jan 12, 2022 at 20:27 | comment | added | Andy | @AlvaroRodriguezScelza Authorization and authentication are business rules, so yes, you would. Can I edit a purchase order is a business decision, not a technical one, so your domain should be able to answer that question in a UI independent way. Http is conceptually part of the UI layer, so no, that happens in your UI layer. | |
| Nov 30, 2021 at 14:22 | comment | added | Alvaro Rodriguez Scelza | @Andy but then wouldn't you have security and maybe http requests processing in your Domain Model? | |
| Jan 9, 2015 at 12:10 | comment | added | Marc Juchli | Those slides cover the explanation regarding service layer and this graphic above pretty neat: slideshare.net/ShwetaGhate2/… | |
| Nov 20, 2014 at 1:32 | comment | added | Andy | Do yourself a favor and kill your service layer. Your ui should use your domain directly. Ive seen this before and your domain invariably becomes a bunch of anemic dtos, not rich models. | |
| Nov 14, 2013 at 17:44 | comment | added | JensG | Absolutely agree with the Gateway. SOAP is (standardized) bloatware, so I had to ask. And yes, no impact on question/answer either. | |
| Nov 14, 2013 at 8:23 | history | edited | gnat | CC BY-SA 3.0 | http://martinfowler.com/eaaCatalog/ServiceLayerSketch.gif |
| Nov 14, 2013 at 8:20 | history | edited | CodeART | CC BY-SA 3.0 | added 103 characters in body |
| Nov 14, 2013 at 8:17 | comment | added | CodeART | REST won't cut it for our requirements. SOAP or REST, this doesn't make any difference to the answer. From my understanding, service is a gateway to domain logic. | |
| Nov 14, 2013 at 0:15 | comment | added | JensG | You decided for SOAP just yesterday? Is that a requirement or did you just have no better idea? | |
| Nov 13, 2013 at 20:37 | history | answered | CodeART | CC BY-SA 3.0 |