Sioux Hot-or-Not 3 mei 2007, Domain Driven Design met Edwin Van Dillen

1. Domain Driven Design with
Lego Mindstroms
Edwin van Dillen
evdillen@sogyo.nl
1
© 1995-2007 Sogyo 1
About Sogyo …
Competence areas:
• Software Engineering
• Software Architecture
• Enterprise Application Integration (EAI)
• Application Management
© 1995-2007 Sogyo 2
1

2. Are you familiar with?
“DDD is about
“Once your mind is as
making the
warped to objects as mine
computer invisible.”
is, you’ll find you prefer a
Domain Model even in
fairly simple cases.”
Rob Vens
Hexagonal Alistair Cockburn
Architecture
Eric Evans
“The hart of software is its ability to solve
domain-related problems for its user.”
Martin Fowler
© 1995-2007 Sogyo 3
Agenda
Why Domain Driven Design?
Introduction in Domain Driven Design
Domain Driven Development
Related technologies and frameworks for
DDD
Roundup and conclusions
© 1995-2007 Sogyo 4
2

3. Why Domain Driven Design?
What is the problem with software?
5
© 1995-2007 Sogyo 5
What is our challenge?
In his work, Larman refers to investigations of
project results and concludes that about 65%
of the requirements that are mentioned at the
beginning of a project, are not relevant
anymore at the end of the project.
Oke, so we have to deal with changes in the
requirement.
Source: “Applying UML and Patterns, 3rd edition”, Craig Larman, Prentice Hall
© 1995-2007 Sogyo 6
3

4. How do change reflect on software?
In order to make software changeable we
need to deal with complexity of in such a way
that it is manageable.
There are two types of complexity [Brooks]:
Essence
Accidental
Source: http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html
© 1995-2007 Sogyo 7
Software Development
Principals to deal with accidental complexity.
Minimum coupling
Maximum cohesion
“Loose coupling is and remains the best way
to master complexity” Based upon Edsgar Wybe
Dijkstra Founder of structured programming
Introduce “Separation of Concerns”
© 1995-2007 Sogyo 8
4

5. Traditional design
Layering model
Interface
Reasons to do so:
Separation of interface, Logic
logic and data
Better maintainability
Data
Better scalability
© 1995-2007 Sogyo 9
Traditional Design
In practice:
Calls folow from top to Interface
bottom
Tight coupling between
Logic
layers
Focus on presentation and
persistence. Data
So layering is not the solution when
dealing with accidental complexity
© 1995-2007 Sogyo 10
5

6. Can different software architecture
styles help?
Transaction Script Table Module
Effort to
Enhance Domain Model
Source:
Martin Fowler
Complexity of Domain Logic
choose the right style for the right application/service
© 1995-2007 Sogyo 11
What is domain driven?
Presentation
Domain
Model
Persistency Messaging
Authentication
© 1995-2007 Sogyo 12
6

7. Why domain driven development?
Most of the development time is still spent on
writing the plumbing logic in stead of the real
business logic;
The appearance of an application changes more
often then the business logic (rule of thumb)
Domain-classes: 10-20 years
Database functions: 5 years
User interface/communication: 2 years
So, we approach the problem by applying an other paradigm!
© 1995-2007 Sogyo 13
Introduction in
Domain Driven Design
The case of the Lego Mindstorms
Robot!
14
© 1995-2007 Sogyo 14
7

8. What is domain modeling about?
“Domain modeling is not a matter of making
as ‘realistic’ a model as possible. Even in a
domain of tangible real-world things, our
model is an artificial creation….”
“It is more like moviemaking, loosely
representation reality to a particular purpose”
Create a common language;
Source: “DDD: tackling complexity in the heart of software” by Eric Evans
© 1995-2007 Sogyo 15
What is a domain model ?
A domain model is an representation of ‘real-
world’ conceptual classes. (bron: [[Eliens])
bron: Eliens
Eliens])
Not about software parts
It is complete independent
© 1995-2007 Sogyo 16
8

9. Domain of the Robot
Meet our robot:
Sound senor
CPU (communication
via Bluetooth)
Pressure senor
Motors
Light senor
Sonar
© 1995-2007 Sogyo 17
Domain of the Robot
To begin with:
© 1995-2007 Sogyo 18
9

10. Domain of the Robot
© 1995-2007 Sogyo 19
Domain of the Robot
© 1995-2007 Sogyo 20
10

11. Testability
The domain model is completely
independent.
So lets test it!
© 1995-2007 Sogyo 21
Domain Driven Development
Gluing the services around the domain
22
© 1995-2007 Sogyo 22
11

12. Now lets implement the domain
Presentation
Domain
Model
Persistency Messaging
Authentication
© 1995-2007 Sogyo 23
The glue between domain and
services
Services
Domain
Presentation
Domain
Adapter
Model
“Convert the interface of a class
into another interface clients
expect.” GoF-adapter pattern
© 1995-2007 Sogyo 24
12

13. The Lego Mindstorms Service
© 1995-2007 Sogyo 25
Adapters
© 1995-2007 Sogyo 26
13

14. Related technologies and frameworks
for DDD
27
© 1995-2007 Sogyo 27
What if my domain is not a Robot?
What about events?
Events from the domain to adaptors and vice versa is
oke.
Be aware of the consequence when using events in the
domain itself.
What about persistency?
Can be written by hand, the use of O/R-bridges is
advised.
© 1995-2007 Sogyo 28
14

15. Support by frameworks for DDD
AOP
For instantiating the domain
Think Postsharp
Persistency
Translation of Objects to Relation structure
Think of NHibernate
NakedObjects…
Choose the application architecture instead of the framework!
© 1995-2007 Sogyo 29
Domain Specific Languages
It often related to DDD;
What does Domain mean here?
“any topic of interest” Keith Short
Domains are used to get the focus on a specific
topic within the whole area of the system
Make solutions easier to understand and maintain
Easy to integrate with development process
Improve agility through rapid iteration
© 1995-2007 Sogyo 30
15

16. DSL and DDD
Domain examples in DSL:
Security (rather broad domain)
Web service security (more specific domain)
Also business domains, such as Health
insurance
So DSL can be applied to support DDD;
We are now building a DSL for persistency
© 1995-2007 Sogyo 31
software architecture
SOA
Enterprise
DOA TOA
Application /
service
© 1995-2007 Sogyo 32
16

17. Roundup and conclusions
33
© 1995-2007 Sogyo 33
Pros and Cons of domain driven
Pros Cons
Separation of concerns; Requires more time at the
start of the development
The domain logic is
project;
centralised;
For the domain to be
The domain model itself can
independent of the services
be tested early in the
requires design experience
project;
Requires good OO skills of
Adding/changing services
developers and analysts;
does not influence the
domain or other services;
© 1995-2007 Sogyo 34
17

18. Lessons Learned: Martin
Fowler/Jimmy Nilsson
In PI don’t do:
Inherit from a certain base class (except domain
classes)
Only instantiate via provided factory
Use specially provided datatypes (such as
collections)
Implement a specific interface
Provide specific constructors
Provide mandatory specific fields
“Persistence Ignorance (PI)”
Martin Fowler
© 1995-2007 Sogyo 35
Lessons Learned by Sogyo
Get a clear understanding of the expected lifespan of the
application
Table driven often looks like a good approach in the first iteration;
A domain model is often smaller than you expect.
Find the right abstraction level
A domain model must have (business) responsibilities.
It is not just about data, but behaviour
Domain modelling is done by domain modellers
They must understand the business and OO
© 1995-2007 Sogyo 36
18

19. Articles
Will be published in the “New Stuff” in April !
Domain Driven Design in de praktijk
Een case met Lego Mindstorms
Will be published in the Java Magazine of
29 March
Domain Driven Design
Achtergrond en ervaringen uit de praktijk
Leave your e-mail address and we will send a PDF
© 1995-2007 Sogyo 37
Resources
Eliens]: Object-
[Eliens]: Principles of Object-Oriented Software
Development, Eliens, Addison-Wesley (2000, 2th
Eliens, Addison-
edition)
Domain-
[Evans]: Domain-Driven Design: Tackling Complexity
Addison-
in the Heart of Software, Evans, Addison-Wesley
(2003)
[Fowler]: Patterns of Enterprise Application
Architecture, Fowler, Addison-Wesley (2003)
Addison-
Vens]: http://www.sepher.nl
[Vens]: http://www.sepher.nl
[Cockburn]:http://alistair.cockburn.us/index.php/Hex
agonal_architecture
[Nilsson]: Applying Domain Driven Design and
Patterns: using .NET
© 1995-2007 Sogyo 38
19

20. Sogyo
Landgoed Sandwijck
Utrechtseweg 301
3731 GA De Bilt
Tel:030 220 22 16
Fax:030 220 55 06
www.sogyo.nl
www.edwinvandillen.com
© 1995-2007 Sogyo 39
20