Abstract

Uncle Bob's talk on Clean Architecture to the the Norfolk developers meetup group

Table of Contents

Screaming Architecture

Application Logic

The interactor derives from the input boundary (i.e., abstract class). The interactor orchestrates the dance of the entities. The output is handed to the output boundary from the interactor.

Business Logic

Boundaries

Boundaries are interfaces or abstract classes. Entities are concrete.

Every reference must go toward the interactor across the boundary. Presentation group and the business logic group should be different packages (DLL, Gem, package, etc.) and be deployed independently.

Independent deployment is the goal between GUI, business logic, and database.

MVC

Model is not allowed to know where it gets its input from. The View registers with the model. Controller passes control to the View.

Model, View, Presenter (MVP 33:00)

The boundary between presenter and interactor is a hard architectural boundary (double black lines). All dependencies, point across the lines. Business logic doesn’t know about MVP. The web is a plugin to the business rules.

Response model has data that is not presentable. Presenter converts those to strings.

Architecture

Application and business logic should be separate from the delivery method and the framework.

These things are simple but not easy. Team skill has a significant impact on what methods your team can use.

Databases became the significant decision because of Oracle and their push for DBAs. Rails made the mistake of making the web and the database the center of everything. Separate the details from the things that are general.

Defer decisions until they become unnecessary. The architect’s job is to defer decisions as long as is possible. A good architecture allows significant decisions to be postponed. The role of an architect is not to make decisions but to defer decisions. This allows the program to be built in the absence of decision. A good architect maximizes the number of decisions not made. The plugin model enables this.

You don’t need to know what web framework you’re going to use. Get all of the business rules working first, get all of the flows working first, and then use a framework.

Entities are not instances of DB tables.

Frameworks

Framework authors are out to screw you. You make a tremendous commitment to the framework, but they do not commit to you. Frameworks come at a cost. They come with benefits but also with costs. Keep them at arm’s length. Don’t follow their examples. Don’t couple your code strongly to it. You should be free to break away from the framework.

Plugins (36:00)

Plugins are vulnerable to the things they plug into. The things that they plug into are immune at compile time. Things that need to be immune from other things should be plugins. The UI should be separate from business rules.

You can test the elements of the plugin architecture independently.

Discipline

The database is a detail. Programmers are abstracters, detail managers.

Architects are not detached from the code. They are merely the best programmers.

The Database

SQL is horrible. The database access layer is textual which is crazy and vulnerable to injection.

The reason for the DB is disappearing. The why for NoSQL.

Don’t bind yourself to the DB. You don’t need disks anymore.

Entity Gateways

Double line boundary for the entity gateway. Has a method on it for every operation you want to perform on the DB. Every sort of query you want to do is behind a method. * getOrdersSince(someDate)

The database is a plugin to the business rules. You can separate the business rules from the DB. This fixes the slow test suite issue. Get the test process to be the QA process.

Dependency Injection (1:09)

You probably don’t want to inject everything. Inject factories and let the business rules use those factories. Don’t inject more than a dozen or two dozen items.

Make injections into a plugin. You don’t want to use cases to know about injection framework.