In Drupal 8, we've tried to break up our procedural codebase into classes, use statics as as a last resort, and abstract the instantiation of these classes with a service container. As we've seen already, this can add a considerably amount of complexity, but we often justify it with the idea that our code is more flexible and unit testable.

The fundamental problem with this approach is that we don't write unit tests. Until very recently with PHPUnit, the only option we had was UnitTestBase which supported using db connections! Lack of real unit testing and a strong desire to make our code DRY to the point of dehydration, has produced tightly coupled components that are difficult to work with and test.

Why is the User class, one of the simplest examples of thing you can model in a class, in the Drupal\user\Plugin\Core\Entity namespace? Our implementation details are so exposed they are in our namespaces!

I would like to see the Drupal community embrace the concept of Models, and start creating classes that encapsulate their business logic in a way that makes them easy to understand and work with.

In this session I will talk about how modeling our classes better and unit testing them will help make Drupal easier to conceptualize and easier to work with in contrib.