Closing the Gap<br />Copenhagen .NET User Group – 23. February 2011<br />Jeppe Cramon<br />
What’s the current status in our work environment?<br />
Typical management thinking<br />We pick the tools and architecture that Gartner recommends<br />More people working on a ...
The problem with AMAG*<br />Management picks what Gartner recommends and feel justified (CMA**) <br />Don’t have to unders...
9 women can deliver a baby in 1 month<br />Increasing the number of developers on a project, decreases developer efficienc...
Closing the Gap<br />We need:<br />Smaller teams (5-10 people)<br /> What if instead of "what languages work for large tea...
What’s this talk about?<br />I will give my experience of how to close the gap as a developer & architect<br />
We can’t control everything<br />But we can try to immunize ourselves from changes that we know will occur<br />
Combine Lean & Agile<br />
Lean<br />A little thinking ahead can save you a lot of pain down the road<br />Architectural refactoring is expensive<br ...
Example<br />WHEN BUILDING <br />A LIFE INSURANCE APPLICATION<br />DEAL WITH  TEMPORAL  DESIGN <br />UPFRONT<br />
Agile<br />Apply your learning's iteratively – It’s the least expensive way<br />Pick the right tools for the right job<br...
Where do we start?<br />
How to get a grasp of the unknown<br />Talk the talk – learn the language of the domain experts<br />Forming our Ubiquitou...
Models -the backbone of Domain Driven Design (DDD)<br />They give us our common language – the ubiquitous language<br />Ar...
Core Principles of DDD<br />The Model and the Design shape each other<br />The binding between Model and implementation, m...
Core patterns<br />Repositories<br />ENTITIES<br />Factories<br />Layered Architecture<br />VALUE OBJECTS<br />Modules<br ...
Entities<br />Motivators: <br />Objects are defined by identity and not by their attributes. <br />May have lifecycle, can...
Value Objects<br />Motivators:<br />Objects which describe thingsand are defined by their attributes (not by their identit...
Aggregates<br />What:<br /><ul><li>Cluster coherent Entities and Value Objects, with complex associations, in to aggregate...
Choose one entity to be root and controlaccess to objects inside the boundary through the root.
External objects hold references to the root </li></ul>Motivation:<br />Control invariants and consistency through the agg...
So now that we have a model sketch – what’s next?<br />
Same procedure as last year?<br />We write our ORM classes and mapping by hand<br />
So we go from<br />
To…By writing<br />package dk.tigerteam.mdsd.demo.model.internal;<br />@Entity<br />@Table(name = "Customer")<br />public ...
This works fairly well, until…<br /><ul><li>We get tired of writing the same tedious code by hand
We suddenly realize that:
Our assumptions didn’t hold up and we need to change  many of our mappings
We need to write a lot of test code to ensure that our mappings are correct
We’re writing a lot of technical code and very little business code</li></li></ul><li>Also<br />Who maintains the models a...
So what is the solution?<br />A “radical” shift – to a larger degree of automation<br /><br />Model Driven Development<br />
Get rid of tedious repetitive code<br />Model<br />Generator<br />Frameworks<br />(Hibernate/JPA, Entity Framework)<br />S...
Let’s get cranking with UMLand TigerMDSD<br />
The process<br /><br /><br />Java/C# code<br />JPA / Entity Framework<br />DB schemas<br />WSDL<br />XML Schema<br />Int...
What’s possible with the Meta Model<br />Just about everything - <br />Set your mind free <br />
What about Domain Logic?<br />It’s important to separate Entity Logic and Use Case Logic<br />Use Case Logic doesn’t belon...
Domain Modeling<br />Domain Object design should focus on WHAT the SYSTEM IS<br />NOT on what the system DOES<br />James C...
Entity Logic<br />We have several options with regards to Entity Logic<br />Optional<br /><br />What we model<br />Altern...
Extension Methods
Priviledged Aspects
Protected Regions</li></ul>Partial classes<br />3 level inheritance<br />
DCI<br />Allows us to separate Form <br />What the System IS – AKA. The domain mode<br />from Structure <br />What the Sys...
Use Case Logic<br />This type of logic spans Domain Objects.<br />Data Context Interaction (DCI) offers a very flexible wa...
DCI<br />Separating Structure from Form is done using Roles, which are (typically) played by Domain Objects<br />Mixins/Tr...
DCI<br />Marriage Context<br />Role Map<br />Interaction<br />Mother<br />Person<br />ID: 2<br />Son<br />Father<br />Pers...
Higher abstraction level<br />Bi-temporal history<br />At any time<br />Over a long period<br />Gives us the freedom<br />...
Versioning (Temporal Object Pattern)<br />
Generating WebServices<br />
Example Extensions<br /> Built-in Types <br /> Bidirectional associations<br /> Property Sugar methods<br /> Get Or New Pr...
The Core of Flexible Code Generator<br />
Upcoming SlideShare
Loading in...5
×

Closing the Gap - DDD, MDD, DCI and Codegeneration

4,116

Published on

How do we close the gap between developers, management and the business experts. After introducing typical management thinking and the problems this presents, I will introduce how I believe we can try to immunize ourselves from the things that are bound to change during a project. This includes Agile & Lean practices, Domain Driven Design (DDD), Model Driven Development (MDD) and Data Context Interaction (DCI).

1 Comment
12 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,116
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
103
Comments
1
Likes
12
Embeds 0
No embeds

No notes for slide
  • E.g.: We want reuse – hence we need SOA and an ESB and then things will magically start working and we will have reuse – aka. The magic silverbullet
  • *Up to 10 developers –Nextjump to increase efficiency is 30 devs – next jump again is 100 devs*Typical developer estimates are multiplied by a factor of 3 to 6 to give the actual time spent
  • Skill: We all need to become more professional. Management needs to understand what they’re trying to manage and developers need to give proper feedback and not only resort to complaining or choosing framework/tools for the fun of it Less CV driven developmentClose contract: Walk the talkAutomation: Continuous Integration, Testing, Deployment, Code generation
  • Why do all project almost always start from scratch – beginning with a clean plate and creating a new architecture – where’s the momentum and gathering of learning&apos;s from previous projects?
  • Domain Entities, Processes, UI’s
  • [Mapped Super Class]^[Abstract A{bg:orange}], [Mapped Super Class]^[Abstract B{bg:orange}],[Abstract B]++-&gt;[A], [Abstract A]+-&gt;[B], [Abstract A]^[A], [Abstract B]^[B]
  • Closing the Gap - DDD, MDD, DCI and Codegeneration

    1. 1. Closing the Gap<br />Copenhagen .NET User Group – 23. February 2011<br />Jeppe Cramon<br />
    2. 2. What’s the current status in our work environment?<br />
    3. 3. Typical management thinking<br />We pick the tools and architecture that Gartner recommends<br />More people working on a project = The faster it gets finished<br />100 foreign developers are better than 10 local, if the price is the same<br />
    4. 4.
    5. 5. The problem with AMAG*<br />Management picks what Gartner recommends and feel justified (CMA**) <br />Don’t have to understand anything related to development<br />Too many silver bullets and magic formulas<br />Developers gets a tool, but not necessarily the right tool for the job<br />AMAG* Architecture by Management, Approved by Gartner<br />CMA** Cover my Ass<br />
    6. 6. 9 women can deliver a baby in 1 month<br />Increasing the number of developers on a project, decreases developer efficiency <br />Communication overhead<br />More ceremony (Documents and Processes)<br />Writing code typically only amounts to 25-30% of the total project time<br />
    7. 7. Closing the Gap<br />We need:<br />Smaller teams (5-10 people)<br /> What if instead of "what languages work for large teams" we looked for "what languages prevent the need for large teams?” – Greg Young<br />More skilled developers and managers<br />Close contact to Product owner and Business Experts<br />Higher level of Abstraction<br />High degree of Automation<br />Shorter feedback cycles<br />Make it cheaper to make mistakes and learn from it<br />
    8. 8. What’s this talk about?<br />I will give my experience of how to close the gap as a developer & architect<br />
    9. 9. We can’t control everything<br />But we can try to immunize ourselves from changes that we know will occur<br />
    10. 10. Combine Lean & Agile<br />
    11. 11. Lean<br />A little thinking ahead can save you a lot of pain down the road<br />Architectural refactoring is expensive<br />Understand the nature of your domain <br />To pick the right abstractions<br />Discover patterns & variations<br />Do enough upfront – but not too much!<br />Focus on learning and improving <br />Reducing waste<br />Why do most projects always start from scratch?<br />
    12. 12. Example<br />WHEN BUILDING <br />A LIFE INSURANCE APPLICATION<br />DEAL WITH TEMPORAL DESIGN <br />UPFRONT<br />
    13. 13. Agile<br />Apply your learning's iteratively – It’s the least expensive way<br />Pick the right tools for the right job<br />Use proper test approaches to ensure quality.<br />This helps you discover when new learning’s break old assumptions<br />Focus on importance and criticality<br />
    14. 14. Where do we start?<br />
    15. 15. How to get a grasp of the unknown<br />Talk the talk – learn the language of the domain experts<br />Forming our Ubiquitous Language<br />Draw a lot of paper sketches<br />Domain Entities (Models), Processes, UI’s<br />
    16. 16. Models -the backbone of Domain Driven Design (DDD)<br />They give us our common language – the ubiquitous language<br />Are a great tool for communication<br />Clearly defines boundaries and help us grasp a complex world<br />
    17. 17. Core Principles of DDD<br />The Model and the Design shape each other<br />The binding between Model and implementation, makes the model relevant<br />The analysis that went into the Model applies to the final product the running program<br />The Model is the backbone of the Ubiquitous language – used by all team members. <br />Closing the Gap – developers talk to business experts without translation<br />The Model is distilled knowledge – Captures how we choose to think about the domain in form of: terms, concepts and the relationship between them<br />The Model isn’t about realism – “Even in a domain of real-world things, our domain model is artificial creation, like movie making…”<br />
    18. 18. Core patterns<br />Repositories<br />ENTITIES<br />Factories<br />Layered Architecture<br />VALUE OBJECTS<br />Modules<br />Services<br />AGGREGATES<br />
    19. 19. Entities<br />Motivators: <br />Objects are defined by identity and not by their attributes. <br />May have lifecycle, can change form by time and context (A Person that becomes a father, which becomes a grand father, etc.)<br />Focus is on Whoand not on what!<br />
    20. 20. Value Objects<br />Motivators:<br />Objects which describe thingsand are defined by their attributes (not by their identity) and doesn’t have a lifecycle.<br />Focus is on What and not on who!<br />
    21. 21. Aggregates<br />What:<br /><ul><li>Cluster coherent Entities and Value Objects, with complex associations, in to aggregates with well defined boundaries.
    22. 22. Choose one entity to be root and controlaccess to objects inside the boundary through the root.
    23. 23. External objects hold references to the root </li></ul>Motivation:<br />Control invariants and consistency through the aggregate root.<br />Enables: Loading schemes, coarse grained locking, consistency boundaries for DDDD<br />
    24. 24. So now that we have a model sketch – what’s next?<br />
    25. 25. Same procedure as last year?<br />We write our ORM classes and mapping by hand<br />
    26. 26. So we go from<br />
    27. 27. To…By writing<br />package dk.tigerteam.mdsd.demo.model.internal;<br />@Entity<br />@Table(name = "Customer")<br />public class Customer extends AbstractEntity{<br /> private static final long serialVersionUID = 2098912667L;<br />@Basic<br />@Column(name = "name", nullable = false)<br /> private String name;<br />@OneToOne(cascade = {<br />CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH},<br />fetch = FetchType.LAZY)<br />@JoinColumn(name = "addressId")<br />@NotNull<br /> private dk.tigerteam.mdsd.demo.model.internal.Address address;<br />@OneToMany(cascade = {<br />CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, <br />targetEntity= Booking.class, mappedBy = "customer", <br /> fetch = FetchType.LAZY)<br /> private Set<Booking> bookingCollection =<br /> new java.util.HashSet<Booking>();<br /> public String getName() {<br /> return name;<br /> }<br />public void setName(String name) {<br />this.name = name;<br /> }<br /> …<br /> …<br /> …<br /> …<br />…<br /> …<br /> …<br />…<br /> …<br /> …<br />}<br />package dk.tigerteam.mdsd.demo.mode.internal;<br />@Entity<br />@Table(name = "Booking")<br />public class Booking extends AbstractEntity {<br /> private static final long serialVersionUID = 170080605L;<br /> @Basic<br /> @Column(name = "comment", nullable = false)<br /> private String comment;<br /> @Basic<br /> @Temporal(TemporalType.TIMESTAMP)<br /> @Column(name = "time", nullable = false)<br /> private java.util.Date time;<br /> @Basic<br /> @Column(name = "timeslot", nullable = false)<br /> private int timeslot;<br /> @ManyToOne(cascade = {<br />CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, <br /> fetch = FetchType.LAZY)<br /> @JoinColumn(nullable = false, name = "customerId")<br /> private Customer customer;<br /> public String getComment() {<br /> return comment;<br /> }<br /> public void setComment(String parameter) {<br />this.comment = parameter;<br /> }<br /> public java.util.DategetTime() {<br /> return time;<br />}<br /> …<br />…<br />…<br />…<br />…<br />…<br />…<br />}<br />@Entity<br />@Table(name = "Address")<br />public class Address extends AbstractEntity {<br /> private static final long serialVersionUID = 1697028161L;<br /> @Basic<br /> @Column(name = "street", nullable = false)<br /> private String street;<br /> @Basic<br /> @Column(name = "zipCode", nullable = false)<br /> private String zipCode;<br /> @Basic<br /> @Column(name = "city", nullable = false)<br /> private String city;<br /> public String getStreet() {<br /> return street;<br /> }<br /> public void setStreet(String parameter) {<br />this.street = parameter;<br /> }<br />…<br /> …<br /> …<br />}<br />
    28. 28. This works fairly well, until…<br /><ul><li>We get tired of writing the same tedious code by hand
    29. 29. We suddenly realize that:
    30. 30. Our assumptions didn’t hold up and we need to change many of our mappings
    31. 31. We need to write a lot of test code to ensure that our mappings are correct
    32. 32. We’re writing a lot of technical code and very little business code</li></li></ul><li>Also<br />Who maintains the models as the code changes?<br />
    33. 33. So what is the solution?<br />A “radical” shift – to a larger degree of automation<br /><br />Model Driven Development<br />
    34. 34. Get rid of tedious repetitive code<br />Model<br />Generator<br />Frameworks<br />(Hibernate/JPA, Entity Framework)<br />Schematic code<br />Interesting code<br />(Hand written)<br />Hand written<br />Libraries (e.g. Java/.NET)<br />
    35. 35. Let’s get cranking with UMLand TigerMDSD<br />
    36. 36. The process<br /><br /><br />Java/C# code<br />JPA / Entity Framework<br />DB schemas<br />WSDL<br />XML Schema<br />Integration tests<br />TigerMDSD<br />MODEL is KING<br />
    37. 37. What’s possible with the Meta Model<br />Just about everything - <br />Set your mind free <br />
    38. 38. What about Domain Logic?<br />It’s important to separate Entity Logic and Use Case Logic<br />Use Case Logic doesn’t belong in Entities (violates coherence)<br />
    39. 39. Domain Modeling<br />Domain Object design should focus on WHAT the SYSTEM IS<br />NOT on what the system DOES<br />James Coplien – DCI Talk at Öredev 2009<br />
    40. 40. Entity Logic<br />We have several options with regards to Entity Logic<br />Optional<br /><br />What we model<br />Alternatives:<br /><ul><li>Mixins / Traits
    41. 41. Extension Methods
    42. 42. Priviledged Aspects
    43. 43. Protected Regions</li></ul>Partial classes<br />3 level inheritance<br />
    44. 44. DCI<br />Allows us to separate Form <br />What the System IS – AKA. The domain mode<br />from Structure <br />What the System DOES<br />Identifying that Form changes much slower than the Structure<br />
    45. 45. Use Case Logic<br />This type of logic spans Domain Objects.<br />Data Context Interaction (DCI) offers a very flexible way of handling this complexity, by allowing Domain Objects to play different Roles within different Contexts (Use cases)<br />
    46. 46. DCI<br />Separating Structure from Form is done using Roles, which are (typically) played by Domain Objects<br />Mixins/Traits/Partial Classes/Extension Methods are used to enhance Domain Objects with extra functionality (Role Methods) within a Context<br />
    47. 47. DCI<br />Marriage Context<br />Role Map<br />Interaction<br />Mother<br />Person<br />ID: 2<br />Son<br />Father<br />Person<br />ID: 3<br />Person<br />ID: 1<br />
    48. 48. Higher abstraction level<br />Bi-temporal history<br />At any time<br />Over a long period<br />Gives us the freedom<br />to chose the right implementation<br />without revealing it in the model<br />What we model<br /><<History>><br />
    49. 49. Versioning (Temporal Object Pattern)<br />
    50. 50. Generating WebServices<br />
    51. 51. Example Extensions<br /> Built-in Types <br /> Bidirectional associations<br /> Property Sugar methods<br /> Get Or New Property methods<br /> Constructor (immutable properties)<br /> Class Hierarchy Java doc generator<br /> Serial Version UID generator<br />MetaType Java doc generator<br />SerializablePojo’s<br />ToString/Equals/HashCode


<br /> JPA Field based persistence<br /> JPA Named Tables and Columns<br /> JPA OptimisticLocking exceptions<br /> Hibernate Foreignkey Constraints<br /> Hibernate Foreignkey Index<br /> Hibernate Fetch Optimization<br /> Hibernate Association Unproxying<br /> Hibernate Table Comments<br /> Hibernate HH-3544 bug fix<br />
    52. 52. The Core of Flexible Code Generator<br />
    53. 53. Model Transformation<br />
    54. 54. Code DOM<br />
    55. 55. An Event Based Extension Model<br />
    56. 56. Extensions<br />
    57. 57. Example Extension<br />
    58. 58. Example Extension - continued<br />
    59. 59. A little statistics<br />Source: http://modelseverywhere.wordpress.com/2010/12/20/more-technology-adoption-curves/<br />
    60. 60. Thanks<br />For more information<br />jeppe@tigerteam.dk<br />or <br />@jeppec on Twitter<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×