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

What is it all about that Domain-Driven Design?

No description
by

Piotr Wyczesany

on 23 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of What is it all about that Domain-Driven Design?

Domain
"A sphere of knowledge, influence, or activity"
Domain-Driven Design Introduction
DDD is hard!
What is it all about
that
Domain-Driven Design?

and why should I care?
Model
Code
Business Value of DDD
Developers focus on the business...
Domain-Driven Design is about
Entities
Value Objects
Aggregates
Repositories
Factories
Domain Services
except is not
...only
Agenda
1. DDD introduction
2. Domain
3. Model
4. Code
5. Business Value of DDD
DDD is
really
hard!
2003
recommended chapters order
1 - 3
11 - end
3 - end
2013
better order
of chapters
fresh view
Why bother?
Complexity
Essential
Accidental
"the critical complexity of most software projects is understanding the business domain itself"
Eric Evans
knowledge crunching
When not to do DDD
when the complexity
is not in the domain
Cat pages
CRUD-like
applications
Eric Evans
"The subject area to which the user applies
a program is the domain of the software"
Eric Evans
it is not technical
Subdomains
Enterprise-like
über model
many functions that make business run
Subdomain types
Core domain
Supporting
subdomain
Generic
subdomain
$$$
Strategic Design
dividing the Domain into Subdomains
is absolutely essential for Domain-Driven Design!!!
Big Ball of Mud
Ubiquitous Language
"The limits of my language
mean the limits of my world"
Wittgenstein
complete vocabulary used in given (sub)domain(s)
reflected in the code
Bounded Context
Context is the king!
Explicit (and named)
boundary
for
language meaning
and
model
.
Context Map
What is a Model?
UML diagram?
Database schema?
Architectural layer?
Model of the universe
http://en.wikipedia.org/wiki/File:Bartolomeu_Velho_1568.jpg
Geocentric
http://pl.wikipedia.org/wiki/Plik:Heliocentric.jpg
Heliocentric
1543
"A
system of abstractions
that describes
selected
aspects of a domain and
can be
used
to solve problems related
to that domain"
Eric Evans
anything more?
Model definition
What about
"the real world"?
All models are
wrong
!
Some models are
useful
.
Do
not
model "the real world"!
Abstract unimportant things
"A designer knows he has achieved perfection
not when there is nothing left to add,
but when there is nothing left to take away."
Antoine de Saint-Exupéry
Model is the Code
...and the Code is the Model
Object-Oriented
Functional
Logic
straight mapping
Programming Paradigms
real
Procedural?
Useful Model
Useful for what?
which is better?
Model is
always
located
in a Bounded Context
which Model of the

universe is
more useful
?
it depends...
Piotr Wyczesany
eventuallyinconsistent.com
@WyczesCalvo
Architecture
Building blocks
Most architectures allow DDD
...some just need couple of changes
Model
Infrastructure
>
(sometimes not possible)
technical details
Bounded Context
Each
may
have
different
architecture
!=

must
right tool for the job
Layers
3-Layered
GUI
Logic
Data Access
DDD?
4-Layered
GUI
Application Layer
Domain Layer
Infrastructure Layer
4-Layered with DI
Infrastructure Layer
GUI
Application Layer
Domain Layer
Hexagonal Architecture
(ports & adapters)
Domain model
Adapters
Adapters
Actor Model of Computation
Actor 1
Actor 3
Actor 2
Actor 4
event-driven, highly distributed
Command Query
Responsibility Segregation
Commands
Queries
Model
Views
Events
GUI
Choose what is
useful
!
... almost at the end...
... but where most people start
... and fail
Value Objects
immutable
no id
Entities
identified
by id
value
expose
behavior
mutable
no setters
Aggregates
root
entity
protect
invariants
transaction
boundary
own
lifecycle
Repositories
stores and loads
aggregates
persistence
mechanism
part of
the Model
Factories
create
aggregates
well-known
pattern
no other
responsibility
Domain Services
not
an Application Service!
no Value Object, nor Entity can handle some business operation
stateless
the
hardest
to understand
Dependency Inversion
... and the organization also learns
Better User Experience...
Clean boundaries...
Developers learn...
... and more maintainable system
... and the Essential Complexity
... and much more
Piotr Wyczesany
@WyczesCalvo
eventuallyinconsistent.com
DDD-KRK
divide et impera
public class
Team {
public void
addPoints(Score matchScore,
PointsCountingSystem pointsCountingSystem) {...}
}
Timetable
Rankings
Team

Team
Match
Position
U
D
public class
Score {

private int
homeTeamGoals;

private int
awayTeamGoals;


public
Score(
int
homeTeamGoals,
int
awayTeamGoals) {...}

public int
homeTeamGoals() {
return
homeTeamGoals; }

public int
awayTeamGoals() {
return
awayTeamGoals; }

// side-effect free

public
Score homeTeamScored() {

return new
Score(homeTeamGoals + 1, awayTeamGoals);
}


public int
hashCode() {...}

public boolean
equals(Object other) {...}

public
String toString() {...}
}
class
MatchHalf {

private

short
id;

private
Score score;

private
Set<Player> playersThatScored;

MatchHalf(
short
id, Score startingScore,
Set<Player> playersThatScored) {

this
.id = id;

this
.score = startingScore;

this
.playersThatScored = playersThatScored;
}


public void
homeTeamPlayerScored(Player player) {
score = score.homeTeamScored();
playersThatScored.add(player);
}
}


public class
Match {

private
UUID id;

private
MatchHalf firstHalf;

private
MatchHalf secondHalf;

private
MatchHalf currentHalf;

Match(UUID id, MatchHalf firstHalf, MatchHalf secondHalf) {

this
.id = id;

this
.firstHalf = firstHalf;

this
.secondHalf = secondHalf;
}


public void
startMatch()
throws
MatchAlreadyStartedException {

if
(currentHalf !=
null
)
throw new
MatchAlreadyStartedException();
currentHalf = firstHalf;
}


public void
homeTeamPlayerScored(Player player) {
currentHalf.homeTeamPlayerScored(player);
}


public void
finishFirstHalf()
throws
FirstHalfAlreadyFinishedException {

if
(currentHalf == secondHalf) {
throw new
FirstHalfAlreadyFinishedException();}
currentHalf = secondHalf;
}
}
package
com.football.model
interface
MatchRepository
extends
CRUDRepository<Match> {}

package
com.football.infrastructure.repository
class
HibernateMatchRepository

extends
HibernateCRUDRepository<Match>

implements
MatchRepository {}

public class
PointsCountingService {

public int
countPointsForHomeTeam(Score score) {

if
(score.homeTeamWon())
return
3;

if
(score.draw())
return
1;

if
(score.awayTeamWon())
return
0;

throw new
IllegalArgumentException("
Score was invalid
");
}
}
Three things to consider
If You
want to improve you OOP, or FP skills
- focus on
Tactical Design Patterns
(although you may fail without Strategic Design at all)
are managing a project
- focus on the
Core Domain
- think where your team will be in 1, 3 and 5 years
want to have better architecture
- focus on
Strategic Design Patterns
- make sure your model is in the center
Step out of your
comfort zone
Anemic Entities with getters and setters
don't do it
Turbo Pascal for Enterprise
Transaction Script in Service
+
=
be explicit!
Summary
Let Your Domain Drive your Design
meetup.com/DDD-KRK
Thank You!
public class
MatchFactory {

public
Match create(UUID id) {

return new
Match(
id,
newMatchHalf(1),
newMatchHalf(2));
}


private
MatchHalf newMathHalf(
short
halfId) {

return new
MatchHalf(
halfId,

new
Score(0,0);

new
HashSet<Player>());
}
}
Full transcript