1

1

1© 1995-2007 Sogyo

Domain Driven Design with Lego Mindstorms

Domain Driven Design with Lego Mindstorms

Edwin van Dillen

evdillen@sogyo.nl

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