As best I can, I try to look at the system as use cases and events. With legacy systems, we are tied to a normalized data model (which is really designed for writing and not reading), so for queries we have to "project" from that normalized data model into another model. But the place I'd really like to get to is storing the system's events, and creating whatever models are necessary to answer queries and fulfill use cases from those events. AKA Event Sourcing <http://docs.geteventstore.com/introduction/3.9.0/event-sourcing-basics/>. I am finally getting to do this on a new project. Our existing systems will stay with a normalized data model for the foreseeable future as the cost of change is too high.
But I still try to take the principles of using business-specific events (like StudentRegistered or PaymentDeclined) in my business logic, then translate those into database calls when they are sent for persistence. That also allows me to use those events to update secondary models or trigger other logic. The common alternative, just updating state and doing `repository.Save()` makes it harder to hook into specific business happenings. On Wednesday, October 26, 2016 at 3:23:44 PM UTC-5, Rupert Smith wrote: > > On Tuesday, October 25, 2016 at 3:12:53 PM UTC+1, Kasey Speakman wrote: >> >> So to phrase what I previously said a different way, a database is the >> wrong level of abstraction to be shooting for. >> > > Yes, I think you are right. Much better if we can just think about the > data model we need, and have some completely automated way of persisting it. > > I was just thinking, with reference to "Making Impossible States > Impossible", typed functional languages have some appealing aspects as a > foundation for describing data models. > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
