Embed Size (px)
DESCRIPTION
Rough slides from my (also rough) talk given at Philly Bar Camp 2014 about conceptual problems facing complex software application projects and what can be done about these problems.
Citation preview
Why do projects drag?Developers don't have domain knowledge
Scope creepBusiness rule changesMisunderstood or uncaptured requirements
Complex code/domainSteep ramp upBugs“Just get something up there”Change is a complexity multiplier
How to fix it
Problem: Developers don't have domain knowledge
Solutions: Short, clear 2 way communication channel Provide tools for domain experts to express domain concepts
and see the results of changes
How to fix it: part 2
Problem: Complex code/domain
Solutions: Comprehensive documentation Comprehensive test suite Minimalist modular code design Common code practices and conventions
3 things developers love to do
Documentation Write Tests Deal with changing user requirements
Abstraction
What a thing is or what needs to be done Opposite of implementation – how a thing is constructed or
how something is done
Goal is to reach simplest representation that still contains all necessary information
The challenge is to match level of abstraction to needs and capacity of people involved
2 way street – both IT concerns and domain knowledge are abstracted
Steve's Web Development rant
Web development has often leaned heavily towards “just getting something up there” and concerned itself with implementation over abstract design
UI focused – UI tools have traditionally been not good at supporting abstraction
Mismatch between HTML and application needs
We are moving to a place where the complexity of applications calls out for abstraction and the tools and practices are coming along to support thinking about things in an abstract manner
MVC – many models to one view
View Model Interface A view can have a defined interface for how it gets handles
the model data. Providing a translation from your data models to the
interface will allow the view to display and interact with it A table can display a 2d array, a list of objects, steps in a
mathematical series, etc.
MVC – many views for one model
Multiple view types of the same model A single data entity can be displayed by any number of
views e.g. Song
Audio in media player Music staff with lyrics Word Cloud Etc.
Domain Driven Design
Iterative navigating the domain to arrive at a level of abstraction that captures the relevant properties of the system while remaining comprehensible to all parties to the design
This is referred to as the Ubiquitous Language
Represents a shift away from UI-focused thinking
Elements of a domain
Entities Value Object Aggregates Events Non-Entity Services Workflows
Entity versus value object
Entity− Identity is important− Properties are mutable
Value Object− Immutable− Generally dependent on containing entity
Entities
Properties Actions Invariants
Entity Properties
These are not necessarily concrete fields
Data− Derived data – rules− Relative data
States− Relative States
Actions
Can be specified at a range of abstractions, from “it does this” to concrete implementation.
Can have expected input-output pairings and constraints attached
Concrete actions
Generally fall into three types− Update entity (CRUD)− Engage non-entity service− Alter workflow state
Invariants
Property level Entity level
Events
Non entity services
Workflows
Aggregates
A collection of related entities Can in some ways be seen as a meta-entity Usually have a single aggregate root entity
Complexes
Entry point Can be contained in a number of constellations
Tests/Behavior specification
Behavior Driven Design− http://www.thoughtworks.com/products/twist-agile-testing
Moving from Abstraction to something usable
Level 1: Communication
Result is a dynamic, multilevel domain map
The real secret is automation
The real real secret is translation
Level 2: Stubs
Interfaces → reference annotated code− Not just models, but tests
Level 3: Full generation
Interfaces → code Auto-generated skeleton UI 2 way binding?
Simple Interface Implementations
Level 4: Dynamic domain systems
Dynamic proxies of not in focus constellations Dynamic, overridable entity/complex states
Dynamic Interface Implementation
Sandbox any sort of state, any constellation
Abstracted actions
Log action call and parameters Combined with data backup, allows replay of system
operation− Automated testing− Shadow data repository
