Architecture - Drawing Lines?

by Roman Heinrich

I'm not the first to chime in about Uncle Bob's Lost Years presentations:

His ideas (maybe not originally his) lure you in with loud promices about clean architecture... This got me thinking... Yeah, I'm easily seduced by cleanness. Sigh...

Here some ideas worth thinking about:

    - Test are not for QA Team, good tests guide YOU
      and allow you to _rapidly_ and _radically_ refactor your code
    - If you're afraid to change something, you're dominated by your creation
    - Good architecture allows deferring decisions
    - Is your application build around a database?
    - Is your application build around a framework?

Some more:

  - Rails is a web delivery mechanism
  - It's a minor implementation detail (WOW)
  - It should be easy to change your framework
  - It should be easy to change your database
  - It should be easy to change your cache store
  - It should be easy to change your background queue
  - It should be easy to change your services

Some implications:

  - your business logic can live in a lib/gem/dll/jar/etc
  - your business logic does not depend on concrete implementations
  - tests for your business logic are damn fast
  - you're not afraid to change it, since it is coverred by tests
  - it has no notion of HTTP-ness in it!
  - divorce the WEB! ))
  - run use-cases without the web-server!
  - delivery(e.g. Web Framework) is a plugin to your Application

Objects with Roles:

  - Entities:
    - have Application independent business rules
  - Boundaries
    - just the Interface(-s) to communicate to/from UseCases
    - nothing special in Ruby, just method names
  - Interactors (UseCases):
    - have Application specific business rules
    - could have a names like: DeleteUserAction, CreateOrderAction, CheckoutAction, etc
  - Presenter:
    - massages the ResponseModel into a viewable structure (ViewModel) (formatting, booleans for checkboxes, etc)
    - can be easily tested - shove in a ResponseModel, check the returned ViewModel
  - ViewModel:
    - is rendered by the View
  - View:
    - dumb renderer
    - can be easily tested - shove in a ViewModel, check the returned HTML
  - Request/Response Models
    - pure data structures, easily created, follow a simple protocol

Request/Response Model


DB and Web Framework irrelevant yet

Presentation (43:00)


Presentation (48:30)

Console Delivery

Presentation (50:50)


Divorce your database will be really hard.... Can't really imagine it in a real complex application without beeing major PITA to use. But I might be wrong. Isolate yourself from Rails - yes, you should do it.