PowerPoint-Prsentation

Command your Domain

Lourens Naude, WildfireApp.com

Background

Independent Contractor

Ruby / C / integrations

Well versed full stack

Architecture

WildfireApp.com

Social Marketing platform

Large whitelabel clients

Bursty traffic Lady Gaga, EA, Gatorade

Audience

Monolithic applications

Scale together, fail together

Often have an anemic domain model, scattered logic

Hockey stick function fast initial growth, increasingly difficult to extend over time

Hacks always have the longest lifecycle in a codebase

Target platforms

Projects with significant complexity

Existing monolithic applications

Environments with excessive coupling or dependencies

MAINTENANCE COST IS MULTIPLE TIMES MORE THAN DEVELOPMENT COST

Anemic Domain Models

Cost to business

No competitive advantage

Long dev production cycle

Identified by ...

Tech oriented interfaces

High coupling to neighboring layers

Coupled persistence

Dependencies on host frameworks

Layered Architecture

Layers

UI

Application

Domain

Infrastructure

Rails && other MVC ?

All of the above, monolithic tree

Modeling is often data driven, not behavior driven

Models / entities are often coupled to conventions and dependencies of the host framework

Problems in practice

Rails as a niche framework

Initial conventions scale for small to medium size applications

Fast time to market

Request / response + rendering

Beyond this, generally not a Rails application anymore

Development and growth

Your application, over time, becomes your framework for future development

Conventions, practices and dependencies should grow with and adapt to that also

APPLICATIONS AS A FRAMEWORK

Custom policies and governance

Cater for both developers + production runtime

Environment support with sanity checks

Configuration management

Dependency management etc.

How ?

Thin framework agnostic layer that provides tooling for developers

Piggyback off known contracts eg. cache['something']

Deprecate framework specific references in code

Prefer SomeApp.cache to Rails.cache etc.

Moving off monilithic apps

How features used to roll out

Slapped onto the existing codebase OR

Spawned a new project, with yet another set of conventions

Topic / feature development branches

Challenges

Team likely not structured to support distributed / decoupled systems

Extreme self-discipline, from everyone

Business Process Model skills is required

DOMAIN MODELLING PRIMER

Digesting a domain

Language

Ban acronyms

Push for a common language dev, product + biz

Be childlike.Why, why, why ...

Open ended

A domain representation is always in flux during development, especially if it's new to developers

It'll be enhanced with new concepts

Weed out vague / deprecated elements

Refactorings at this level is often overlooked

Refactoring strategies

Continuously throw usage scenarios at your system

Refactor to deeper insights

Extract hidden concepts look for edge cases, policies etc.

In cooperation with domain experts

Refactor your domain first, code second

Behavior and responsibility

Ignore schema and attributes

Should not be the core of your design process

Assigning data to entities prior to knowing that they do ?

Behavior

Partition objects and entities by behavior

Distribute responsibilities first

Then decide what each entity needs to know

DOMAIN FRAGMENTATION

Domain leaks - People

Developers

Code ownership

Some developers don't communicate well

Snapshot thoughts to wiki != fun

People come, people go

Product and business

Not willing to get into domain details

Concerned with features

Concerned with cash flow

Domain leaks Process

Reorganization

Migrates knowledge excessively

Fine balance between code ownership and moving developers around too much

Practices and culture

Lack of Documentation culture

Not factoring clued up domain experts into projects

Shielding departments from each other us VS them

Visual communication.Whiteboards ? Diagrams ?

Domain discussions encouraged ? Shot down ?

Domain leaks - concepts

Implicit concepts

Instrumental in understanding a model

But never referenced in an implementation

Frequently would be hinted at, but may not seem important to pull in

Explicit concepts

Merging implicit concepts back into the domain

Over time, this leads to breakthroughs

Less edge cases

Ability to handle offline process programatically

Notes on errors

Common error types

Runtime errors

Exceptions

Errors in business logic

Explicit domain errors

Don't inline raise

Do include business errors in your domain

Define strategies for offline or programatic handling

STATE OF YOUR DOMAIN

Loosely coupled domain

-------------------------------------- X