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

DDD inside Ports & Adapters

Ports & Adapters Architecture + Domain Driven Design
by

Sławek Sobótka

on 21 August 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of DDD inside Ports & Adapters

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
Domain Building Blocks
Unit Tests
100 + 100 + 100 = 300
(Order)
(Invoice)
(BookKeeper)
End2end
tests
100 * 100 * 100 = 1 000 000
(Order)
(Invoice)
(BookKeeper)
Supple Design
Order
BookKeeper
Invoice
<<Aggregate>>
<<Aggregate>>
<<Domain Service>>
Tax Policy
domain operation
closure
<<Factory>>
<<Value Object>>
Immutable
functional
Maybe only 1% is possible
...but which 1%?
D
omain
D
riven
D
esign

Sławomir Sobótka
Classic
Application Architectures

Ports & Adapters
Architecture

Micro Kernel
Pipes & Filters
Layers
Command-query Responsibility Segregation
źródło: E. Evans, Domain Driven Design, 2003
PORTS
ADAPTERS
Testability
KERNEL
Impl
implements
PurchaseApplicationService{
<<Interface>>
Services (API)
<<Interface>>
Read API
Modeling
Use Case
User Story
Read Model
<<Interface>>
Repository/DAO
Domain Persistence
ORM (remember about whole Aggregate optimistic locking)
SOA
...
<<Interface>>
Infrastructure
"technical" services
<<Interface>>
Events Publisher
Asynchronous
Web App
Webservice
REST
JSON
Binary
Listener/
Receptor
Acceptance Scenario
Component Test
Command
+
Handler
<<Event>>
<<Event>>
<<DTO>>
ORM
JDBC
noSQL
Fake/Stub/Mock
JMS
...
Fake/Stub/Mock
WS
REST
Binary
...
Fake/Stub/Mock
<<Event>>
ADAPTERS
PORTS
KERNEL
<<Interface>>
Events Publisher
Asynchronous
<<Event>>
JMS
...
Fake/Stub/Mock
unit tests
integration (technical abstraction) tests
end2end - component
end2end - system
Hexagon penetration
Sales
Bounded Context
Payment
Bounded Context
Production
Bounded Context
Transport
Bounded Context
Saga
(model of the time)
Sławo + Mir
Ancient Slavonic language:
"someone who cherish a peace"
Ancient Slavonic festivity:
Sabbath
the shortest night: 21-22 Jun
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
Saga
Product
equivalent
adviser
Discount
assistant:)
Ports & Adapters can integrate them all
as a coherent metaphor
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?
CRM Bounded Context
THE MODEL
Layers - boulding on the top of another layer
P&A - building from the center
P
orts
&

A
dapters

inside
Domain does not "leak"
public number is better than DB ID
Story/Case Scenario
TX and Security via AOP
"offered" ports
"required" ports
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
ADAPTERS
PORTS
KERNEL
Full transcript