• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sioux Hot-or-Not: Domain Driven Design (Edwin Van Dillen)
 

Sioux Hot-or-Not: Domain Driven Design (Edwin Van Dillen)

on

  • 3,827 views

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

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

Statistics

Views

Total Views
3,827
Views on SlideShare
3,815
Embed Views
12

Actions

Likes
0
Downloads
84
Comments
0

1 Embed 12

http://www.slideshare.net 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sioux Hot-or-Not: Domain Driven Design (Edwin Van Dillen) Sioux Hot-or-Not: Domain Driven Design (Edwin Van Dillen) Presentation Transcript

    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Domain of the Robot © 1995-2007 Sogyo 19 Domain of the Robot © 1995-2007 Sogyo 20 10
    • 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
    • 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
    • The Lego Mindstorms Service © 1995-2007 Sogyo 25 Adapters © 1995-2007 Sogyo 26 13
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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