Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Closing the Gap - DDD, MDD, DCI and Codegeneration


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).

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 />
  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 /> = 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:<br />
  60. 60. Thanks<br />For more information<br /><br />or <br />@jeppec on Twitter<br />