Talks by Robert Martin

Clean Architecture and Design

Model-View-Presenter

architecture-diagram

vocabulary

  • An interactor is an object, potentailly a command when using the Command Pattern, which implements a use case. Interactors have application-specific business rules.
  • An entity, or business model, contains application-agnostic rules.
  • A boundary, typically an interface, is the API through which request/response models flow in or out of an interactor.
  • Request/response models are delivery mechanism-independent representations of the inputs/outputs of your application.
  • A presenter takes a response model from a boundary and converts it into a view model.
  • A view model encapsulates any data required by your delivery mechanism (eg. the web).
  • A component boundary defines a boundary with unidirectional dependencies; everything on one side is a plugin to the other.
  • A delivery mechanism is how the end user interacts with the system, eg: HTTP.
An interactor depends on many things; nothing depends on an interactor.

Quotes

Architecture is about intent.

The web is a delivery mechanism!

The web should be a plugin to your application.

Why would the IO channel dictate the structure at the highest level of our application?

The database is a detail.

A good architect maximizes the number of decisions not made.

Takeaways

Your source code, right down to the file structure, should be expressive of the intent of your application. You should be able to immediately infer what your application does just by looking at the filesystem.

The web is your UI layer; it should not define your application. Your application should run as readily on the command line as through a web server.

Your framework should be treated as a UI plugin and abstracted away from your application. Your framework may rely on the application, but the application must not rely on the framework.

Your database should be treated as a persistence plugin and abstracted away from your application. Boundaries can be concerned with the minutia of translating your application between different persistence implementations.

Think of the application as a group in use cases which describe intent, and then a group of plugins which give those use cases access to the outside world.

Object-Oriented Software Engineering

A use case is a description of an action a user will perform on the system.

  • Data describes any data being manipulated by the use case.
  • Primary course describes the step-by-step process taken to instantiate, process, and resolve the use case.
  • Exception course describes how to recover from expected fail states from the use case.

Use cases should be implementation-agnostic. Perhaps the data is collected in a web-form and the primary course resolves to a database-generated id, but those details will not be included in the use case documentation. These are details and subject to regular, potentially radical change.