YOW West 2017 OUR SPONSORS Cost of a dependency Lee Campbell - - PowerPoint PPT Presentation

YOW West 2017

OUR SPONSORS

Cost of a dependency

Dev at Cashies Trainer – Practical Rx

Lee Campbell

Author of eBook and website IntroToRx.com Conference Circuit

Project success

Longevity

How long will your project need to be used for? How long will it need to be maintained for? How long will each of it’s dependent parts be relevant for?

Freedoms

Single man dependencies vs Fungible assets Technology lock-in vs Technology agnostic

A case study

A COLLECTION OF EXPERIENCES

A case study

How did it get like this?

COMPOUNDING EFFECTS

• 1. Single repo

Single repo

\GUI \Server \Datastore

Single repo

\GUI

• FeatureA
• FeatureB

\Server

• FeatureA
• FeatureB
• Shared

\Datastore

Single repo

\GUI

• FeatureA
• FeatureB
• FeatureC

\Server

• FeatureA
• FeatureB
• FeatureC
• Shared
• Logic
• Scripts (Builds, Deployments)

\Datastore

Single repo

\GUI

• FeatureA
• FeatureB
• FeatureC

\Server

• FeatureA
• FeatureB
• FeatureC
• Shared
• Logic
• Scripts (Builds, Deployments)

\Datastore

• FeatureA
• FeatureB
• FeatureC

Single repo

\GUI

• FeatureA
• FeatureB
• FeatureC
• Shared

\Server

• FeatureA
• FeatureB
• FeatureC
• Shared
• Logic
• Contracts

\Framework

• Comms Layer
• Data Persistence abstraction
• Scripts (Builds, Deployments)

\Datastore

• FeatureA
• FeatureB
• FeatureC

Single repo

Who defines requirements and budget for each part of the system? Can this progression be maintained for the expected lifetime of the system? Do these things change together?

Single repo - Consequences

Build times increase Testing burden Friction to innovate Blurry boundaries Lack of responsibility

• 2. Depend on

abstractions

Interface all the things

View Models Translators Validators

Consequences

Testing now becomes an exercise in mocking Debugging is always a case of hitting finding "implementations of"

Consequences

Focus is diluted Cognitive load is increased through indirection

Depend on (external) abstractions

We can also take dependencies on interface define by someone else So maybe you just mock out your

• IoC Continer
• SqlConnection
• ORM UnitOfWork

But these are normally defined in their package, with the implementation.

• 3. Deep layering

Deep layering

Deep system dependencies

Deep layering

Deep layering

My application

• My libraries
• My Framework
• My Framework subsystem
• Generic public packages
• Low level generic public packages

Deep layering

My application

• My libraries (Domain, Data Access, Comms, Controls, Styles)
• My Framework (DataAccess, Comms, Contracts, Generic Utilities, Controls, Styles)
• My Framework subsystem (Implementation specific DataAccess, Comms etc)
• Generic public packages (ORM, Serializers, Web Platform, Messaging, Document manipulation)
• Low level generic public packages (Network interfaces, Collections Libraries)

Deep layering

Non linear growth 3 deep with each dependency having 3 children 1 + 3 + 9 = 13 total

Deep layering

Non linear growth Add 2 more layers (5 layers) 1 + 3 + (9 * 13) = 121 total

1 1 1 1 13 13 13 13 13 13 13 13 13

Deep layering

Non linear growth Add 2 more layers (7 layers) 1 + 3 + (9 * 121) = 1093 total

1 1 1 1 121 121 121 121 121 121 121 121 121

+ baggage

Packages that include

• minified and original resource
• Documentation (JavaDoc/Intellisense)
• Tooling

Deep call stacks

I depend on abstractions But they also depend on abstractions So I have deep call stacks

Deep call stacks

https://twitter.com/gregyoung/status/ 734713437146734592

Consequences

Cognitive load increases exponentially with each layer Technical freedom is slowly eroded as each layer add more dependencies

Compounding Consequences

Compounding consequences

Build times Test times Lack of Ownership

Compensating behaviour

Magic Build scripts Using the real IoC Container in tests AOP

Complicated becomes complex

Cant be rationalised about Emergent behaviour (bugs, not features)

Alternatives

IS THERE A BETTER WAY?

Single repo

FEATURE DEPENDENCY

If it changes together, it lives together

Ways to identify

• The person that has final say on requirements is different
• Release cadences are different
• Code change cadence is different
• Failures are ignored

"Decompose your applications based on volatility" - Juval Lowy

Single repo

\GUI

• FeatureA
• FeatureB
• FeatureC
• Shared

\Server

• FeatureA
• FeatureB
• FeatureC
• Shared
• Logic
• Contracts

\Framework

• Comms Layer
• Data Persistence abstraction
• Scripts (Builds, Deployments)

\Datastore

• FeatureA
• FeatureB
• FeatureC

Multi repo

FeatureA

• GUI
• Server
• DataStore
• Contracts

FeatureB

• GUI
• Server
• DataStore
• Contracts

FeatureC

• GUI
• Server
• DataStore
• Contracts

GUI Lib Comms Lib Persistence Lib

Multi repo

Inherently parallel to build and test Forces the discussion about design by contract Can reduce the knee jerk reaction to share code

Encapsulation

Justify the interface

What is the benefit of this being injected? Can it be encapsulated into this unit?

Private by default

Instead of Reuse being a goal, aim for encapsulation. Rule of 3 Reuse is an evolution

The snip rule

Avoid dependencies that require finesse to remove Single line to cut

Code in action

A DOMAIN MODEL WITH NO DEPENDENCIES

Only depends on .NET

So how does it do anything

The Domain Model defines the interfaces for the things it needs

• IRepository<T>

Can you tell what technology we are using here? Consumers are responsible to implement it We are isolating the business logic from our technology choices.

Inversion of Control

Hosts compose shallow dependencies

Hexagonal Architecture (Alistair Cockburn)  Ports and Adapters  Onion Architecture

We define our Ports

IRepository is one of our ports We may have a SQLServer adapter, or perhaps a MongoDB one

Composition

App Service Domain Model

Data Service

ORM Data store

Comms Service

Serialization Messaging platform

Composition

Domain Model Comms adapter Data adapter App Service Data store Comms

Adapters

CODE BREAK OUT

Composition instead of AOP

I can just use normal old Decorator pattern

Results

Multi repo

• Division of labour
• Cohesive code base
• Reduced cognitive load
• Technical freedom

Results

Encapsulation

• Reduced cognitive load
• Less busy work
• Snip rule

Results

Inversion of Dependencies / Ports and Adapter

• Focused code
• Fast tests
• Shallow stacks
• Technical Freedom

Know your costs

Cognitive load Onboarding friction Technical Freedom Time to prod

More information

LeeCampbell.com Implementing Domain Driven Design – Vaugh Vernon Greg Young – Good enough software Hex Arch – Alistair Cockburn

Having the computer to do what you want isn’t the hard part, having a person understand the intent of your code is.