tag:blogger.com,1999:blog-6579772240267288367.post2562310898071026704..comments2023-06-05T08:45:12.716-04:00Comments on kwblog: Slicing Concerns: ImplementationsKevin Berridgehttp://www.blogger.com/profile/13759114853595462455noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6579772240267288367.post-33677853673036038182012-12-21T10:57:58.205-05:002012-12-21T10:57:58.205-05:00What about an example similar to your last one, bu...What about an example similar to your last one, but where TaskInfo is not an AR, does not have a Save() method? I'm thinking about the separation of data/logic from actual mutations here. What if there were "mutation" services, one that persists the task info (TaskRepo?), and another that sends email notifications for tasks (TaskNotifier?). This gives us the composibility we need to do one or the other or both in a specific scenario. It also solves the problem of the dev discovering what to use, because the dev CANNOT perform the mutations they will need without finding the specific mutation services that implement them. It also avoids dependency injection, inheritance, and the decorator pattern completely. What do you think an app stack based on this separation would look like? What are the practical problems implementing it?Anonymousnoreply@blogger.com