Hands-on Experience: What It Means to Design a Domain Model

The expression “Domain Model” is one of the most abused expressions of the recent history of software. Everyone talks about it; everyone thinks everyone else is doing it and therefore everyone claims they are doing it. Yes, but how? Entity Framework and Code-First have a role in this. Built with the database persistence in mind, Entity Framework has never been sold for what it actually is—a plain simple O/RM. It makes a point of letting you use classes to express the domain and then persist it. This approach makes for intriguing demos at conferences but may not work as smoothly in the real world. And has little to do with domain-driven design and domain modelling. The point is not in how you write classes and partition logic around database tables. The point is how you organize the business rules and how you save, alter and read back the state of the system. Through a comprehensive and quite interactive example, the session will try to make two key points. A single model doesn’t fit all sizes of applications and the domain model is a quite a different thing that the persistence model that Entity Framework Code First is all about.

Dino Esposito

Dino Esposito, JetBrains

A long-time trainer and top-notch consultant, Dino is the author of many popular books for Microsoft Press which have helped the professional growth of thousands of .NET developers and architects. CTO of a fast-growing company providing software and mobile services to professional sports, at the moment Dino is also a technical evangelist for JetBrains, where he focuses on Android and Kotlin development, and a member of the team that manages WURFL – the database of mobile devices used by organizations such as Google and Facebook. Recently, Dino co-authored (along with Andrea Saltarello) the second edition of bestseller Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press). Follow on Twitter: @despos