Use-Case Driven Design: Interactors, Entities, and Boundaries

Wait, what? I thought it was Model-View-Controller. Nope. That’s for a user interface. The UI is a detail. The database is a detail. Your application is neither. And it’s certainly not a detail.

So what is your application? It starts with a use case. A use case makes no mention of the UI or the database. Your use case is delivery and storage agnostic. Your use case is about business logic.

Your application is divided into interactors and entities. The interactors contain use-case specific business logic. The entities contain use-case agnostic business logic. The interactors orchestrate the interaction of entities to satisfy a use-case.

The UI depends on your application (through Boundary interfaces). The persistence gateway depends on your application (through Boundary interfaces). Your application depends on neither the UI or the persistence gateway. Your application is pure business logic. Not convinced? Watch Uncle Bob’s Ruby Midwest 2011 Keynote, “Architecture: The Lost Years”. Or better yet, check out Episode 7 of the cleancoders.

Uncle Bob makes a fabulous point in both of those videos. Software architecture isn’t about frameworks or databases. It’s not about Rails, or Struts, or Hibernate, or NoSQL. It’s about deferring decisions about those kinds of details as long as possible. Whenever you draw a boundary in your system, the lines of dependencies should only cross one way. That is the definition of software architecture.

Saturday, February 11, 2012   ()