1
1
1© 1995-2007 Sogyo
Domain Driven Design with Lego Mindstorms
Domain Driven Design with Lego Mindstorms
Edwin van Dillen
2© 1995-2007 Sogyo
About Sogyo …About Sogyo …
Competence areas:
• Software Engineering
• Software Architecture
• Enterprise Application Integration (EAI)
• Application Management
2
3© 1995-2007 Sogyo
Are you familiar with?Are you familiar with?
“DDD is about making the
computer invisible.”
Rob Vens
Martin Fowler
Eric Evans
Alistair Cockburn Hexagonal Architecture
“The hart of software is its ability to solve domain-related problems for its user.”
“Once your mind is as warped to objects as mine is, you’ll find you prefer a Domain Model even in fairly simple cases.”
4© 1995-2007 Sogyo
AgendaAgenda
� Why Domain Driven Design?
� Introduction in Domain Driven Design
� Domain Driven Development
� Related technologies and frameworks for DDD
� Roundup and conclusions
3
5
5© 1995-2007 Sogyo
Why Domain Driven Design?Why Domain Driven Design?
What is the problem with software?
6© 1995-2007 Sogyo
What is our challenge?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 changeschangeschangeschanges in the requirement.
Source: “Applying UML and Patterns, 3rd edition”, Craig Larman, Prentice Hall
4
7© 1995-2007 Sogyo
How do change reflect on software?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
8© 1995-2007 Sogyo
Software Development 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”
5
9© 1995-2007 Sogyo
Traditional designTraditional design
�Layering model
�Reasons to do so:
�Separation of interface, logic and data
�Better maintainability
�Better scalability
Interface
Logic
Data
10© 1995-2007 Sogyo
Traditional DesignTraditional Design
�In practice:
�Calls folow from top to bottom
�Tight coupling between layers
�Focus on presentation and persistence.
Interface
Logic
Data
So layering is not the solution when
dealing with accidental complexity
6
11© 1995-2007 Sogyo
Can different software architecture styles help? Can different software architecture styles help?
Effort to
Enhance
Complexity of Domain Logic
Transaction Script Table Module
Domain Model
Source:
Martin Fowler
choose the right style for the right application/service
12© 1995-2007 Sogyo
What is domain driven?What is domain driven?
Authentication
Presentation
Domain
Model
Persistency Messaging
7
13© 1995-2007 Sogyo
Why domain driven development?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!
14
14© 1995-2007 Sogyo
Introduction in Domain Driven Design
Introduction in Domain Driven Design
The case of the Lego MindstormsRobot!
8
15© 1995-2007 Sogyo
What is domain modeling about?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
16© 1995-2007 Sogyo
What is a domain model ?What is a domain model ?
�A domain model is an representation of ‘real-world’ conceptual classes. ((((bronbronbronbron: [: [: [: [EliensEliensEliensEliens])])])])
�Not about software parts
�It is complete independent
9
17© 1995-2007 Sogyo
Domain of the RobotDomain of the Robot
� Meet our robot:
MotorsLight senor
Sound senorCPU (communication
via Bluetooth)
Sonar
Pressure senor
18© 1995-2007 Sogyo
Domain of the RobotDomain of the Robot
� To begin with:
10
19© 1995-2007 Sogyo
Domain of the RobotDomain of the Robot
20© 1995-2007 Sogyo
Domain of the RobotDomain of the Robot
11
21© 1995-2007 Sogyo
Testability Testability
� The domain model is completely independent.
� So lets test it!
22
22© 1995-2007 Sogyo
Domain Driven DevelopmentDomain Driven Development
Gluing the services around the domain
12
23© 1995-2007 Sogyo
Now lets implement the domainNow lets implement the domain
Authentication
Presentation
Domain
Model
Persistency Messaging
24© 1995-2007 Sogyo
The glue between domain and servicesThe glue between domain and services
Domain
Model
Services
Domain
Presentation
Adapter
“Convert the interface of a class
into another interface clients
expect.” GoF-adapter pattern
13
25© 1995-2007 Sogyo
The Lego Mindstorms ServiceThe Lego Mindstorms Service
26© 1995-2007 Sogyo
Bootstrapping the systemBootstrapping the system
14
27© 1995-2007 Sogyo
AdaptersAdapters
28© 1995-2007 Sogyo
Handling eventsHandling events
15
29
29© 1995-2007 Sogyo
Related technologies and frameworks for DDD
Related technologies and frameworks for DDD
30© 1995-2007 Sogyo
What if my domain is not a Robot?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.
16
31© 1995-2007 Sogyo
Support by frameworks for DDDSupport 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!
32© 1995-2007 Sogyo
Domain Specific LanguagesDomain 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
17
33© 1995-2007 Sogyo
DSL and DDDDSL 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
34© 1995-2007 Sogyo
software architecturesoftware architecture
SOA
TOADOA
Enterprise
Application /
service
18
35
35© 1995-2007 Sogyo
Roundup and conclusionsRoundup and conclusions
36© 1995-2007 Sogyo
Pros and Cons of domain drivenPros and Cons of domain driven
ProsProsProsPros
� Separation of concerns;
� The domain logic is centralised;
� The domain model itself can be tested early in the project;
� Adding/changing services does not influence the domain or other services;
ConsConsConsCons
� Requires more time at the start of the development project;
� For the domain to be independent of the services requires design experience
� Requires good OO skills of developers and analysts;
19
37© 1995-2007 Sogyo
Lessons Learned: Martin Fowler/Jimmy NilssonLessons 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
38© 1995-2007 Sogyo
Lessons Learned by SogyoLessons 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
20
39© 1995-2007 Sogyo
ArticlesArticles
Will be published in the “New Stuff” in April !
� Domain Domain Domain Domain DrivenDrivenDrivenDriven Design in de praktijkDesign in de praktijkDesign in de praktijkDesign in de praktijkEen case met Lego Mindstorms
Will be published in the Java Magazine of 29 March
� Domain Driven DesignAchtergrond en ervaringen uit de praktijk
Leave your e-mail address and we will send a PDF
40© 1995-2007 Sogyo
ResourcesResources
� [[[[EliensEliensEliensEliens]: Principles of Object]: Principles of Object]: Principles of Object]: Principles of Object----Oriented Software Oriented Software Oriented Software Oriented Software Development, Development, Development, Development, EliensEliensEliensEliens, Addison, Addison, Addison, Addison----Wesley (2000, 2th Wesley (2000, 2th Wesley (2000, 2th Wesley (2000, 2th edition)edition)edition)edition)
� [Evans]: Domain[Evans]: Domain[Evans]: Domain[Evans]: Domain----Driven Design: Tackling Complexity Driven Design: Tackling Complexity Driven Design: Tackling Complexity Driven Design: Tackling Complexity in the Heart of Software, Evans, Addisonin the Heart of Software, Evans, Addisonin the Heart of Software, Evans, Addisonin the Heart of Software, Evans, Addison----Wesley Wesley Wesley Wesley (2003)(2003)(2003)(2003)
� [Fowler]: Patterns of Enterprise Application [Fowler]: Patterns of Enterprise Application [Fowler]: Patterns of Enterprise Application [Fowler]: Patterns of Enterprise Application Architecture, Fowler, AddisonArchitecture, Fowler, AddisonArchitecture, Fowler, AddisonArchitecture, Fowler, Addison----Wesley (2003)Wesley (2003)Wesley (2003)Wesley (2003)
� [[[[VensVensVensVens]: ]: ]: ]: http://http://http://http://www.sepher.nlwww.sepher.nlwww.sepher.nlwww.sepher.nl� [[[[Cockburn]:http://alistair.cockburn.us/index.php/HexCockburn]:http://alistair.cockburn.us/index.php/HexCockburn]:http://alistair.cockburn.us/index.php/HexCockburn]:http://alistair.cockburn.us/index.php/Hex
agonal_architectureagonal_architectureagonal_architectureagonal_architecture� [Nilsson]: Applying Domain Driven Design and [Nilsson]: Applying Domain Driven Design and [Nilsson]: Applying Domain Driven Design and [Nilsson]: Applying Domain Driven Design and
Patterns: using .NETPatterns: using .NETPatterns: using .NETPatterns: using .NET
21
41© 1995-2007 Sogyo
SogyoSogyo
Landgoed SandwijckUtrechtseweg 3013731 GA De Bilt
Tel:030 220 22 16Fax:030 220 55 06
www.sogyo.nl
www.edwinvandillen.com