Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Model is all you need (in business applications)

what I have learned about DDD after 6 years of practicing and teaching
by

Sławek Sobótka

on 12 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Model is all you need (in business applications)

Sławomir Sobótka
slawomir.sobotka@bottega.com.pl
http://art-of-software.blogspot.com
http://code.google.com/p/ddd-cqrs-sample/
http://ssepp.pl
Domain Model
Application Logic
Capability
Operations
Policy
Decision Support
Operational Level
Knowledge Level
Business resources
Potential, possibilities
Low impact of changes
Business state, activity and plans
Utilized possibilities
Medium impact of changes
Goals, rules (law)
Strategies, constraints
High impact of changes
Analytic engines
"Intelligence"
Low impact of changes
Supple Design
Order
BookKeeper
Invoice
<<Aggregate>>
<<Aggregate>>
<<Domain Service>>
Tax Policy
domain operation
closure
<<Factory>>
<<Value Object>>
Immutable
functional
czego nauczyłem sieę podczas szesciu lat praktykowania i nauczania DDD
Impl
implements
PurchaseApplicationService{
We need just one little
change...
Add one tiny checkbox
100 man-days/storypoints/...
but...
technical debt!
Different mental model
of the significance
of the change
Different mental model
of the current "health"
of the project
"What we have got here
is failure
to communicate"
User Story / Use Case Model
Domain Driven Design
Model of the business dynamics
Model not just vision or nouns dictionary
Model is implemented 1-to-1 in source code . Code is the model
Main focus (not UI flow or DB schema)
Driver of the project (ROI, competitive advantage)
Best people, technical debt reduction
Sphere of the business knowledge - common understanding (Ubiquitous Language)
Iterative learning (Knowledge Crunching)
Focus on Core Domain (leave Supporting and Generic)
Source of the essential complexity
Domain
Expert
Modeler
(hands on dev)
knowledge
model
knowledge
about "new" reality
created by IT
validation of
the common understanding
protect invariants!
a + b = c
Building Blocks
Product
equivalent
adviser
Discount
assistant:)
PricingPlan
<<Value Object>>
Purchase
<<Aggregate>>
generatePricingPlan(RebatePolicy)
<<Function>>
<<domain service>>
if prices did not change
in the "meantime"
Model says: we can issue and Invoice for just one Order
but we are smart, we can "hack" model by creating FakeOrder that extends Order:)
... but what would Your mom and Domain Expert say?
THE MODEL
Domain does not "leak"
public number is better than DB ID
Story/Case Scenario
TX and Security via AOP
Complexity
Essential
Accidental
Nature of the problem
unavoidable
Inherited from the solution
boundless:)
Snapshot of the current Product
data (ex. price)
Effective cost (including
current Discount)
Can be used as an
Evidence (ex. copyrights)
Different level of abstraction: concepts like Purchase and PricingPlan can be hidden
What drives your design?
Problem: UI flow is the only "model"
Problem: poor literature is the only "model"
UI FLOW
PROCESS
API
DOMAIN MODEL
flow
modify
Use Case vs User Story
"Just" a requirements model
abstract vs concrete cognitive
strategies
Customer orders products

Narrative:
In order to buy interesting
products
As a
customer
I want to browse the available products, pick the ones that I like and
order
them

Scenario:
client puts some products into
baskets
and checks out
Given Products are available
When I add any product to basket
Then Basket should contain 1 item
When I checkout
Then I should be able to
submit
order with 1 product
When I submit the order
Then That order should be
confirmed
Specification by Example:
business goal oriented
Story:
goal, goal, goal
alternative scenarios to reach the goal
not a "ui clicks" script
BDD approach: user activity scenario
DDD approach: Building Blocks scenario

Domain or Application feature
Ask Domain Expert?
Overlooked Domain
Overgrown application layer (also test)
Problems:
Hide ignorance
General Problem: Overgeneralization
statuses + monster (multi-level) switch statements
flags, flags, flags
"sparse" State Machines
3-flavors of business logic
Stable Logic
Closure (Extension Point)
Which closure?
Aggregate
Domain Service
Policy
Specification
Factory
<<Domain Service>>
BookKeeper
Open-close Principle (SOLID) in practice
<<Interface>>
TaxPolicy
Factory
choose
inject
Do not hack your model
Agile/Lean/Waterfall
Iterations NOT Incrementation
angle of incidence == angle of reflection (STUPID!)
Reservation
what I have learned about DDD during 6 years of practicing
and teaching
Sławomir Sobótka
Sławo + Mir
Ancient Slavonic language:
"someone who cherish a peace"
Ancient Slavonic festivity:
Sabbath
the shortest night: 21-22 Jun
Model is all you need (in business applications)
Model jest wszystkim czego potrzebujesz
(w aplikacjach biznesowych)
Sławomir Sobótka
Sławomir Sobótka
slawomir.sobotka@bottega.com.pl
http://art-of-software.blogspot.com
http://code.google.com/p/ddd-cqrs-sample/
http://ssepp.pl
Model is all you need (in business
applications)
what I have learned about DDD after 6 years of practicing
and teaching
czego nauczyłem sieę podczas szesciu lat praktykowania i nauczania DDD
Model jest wszystkim czego potrzebujesz
(w aplikacjach biznesowych)
Full transcript