Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Where do I put my Business Logic? - Greach 2014, Madrid, Spain

Where do I put my Business Logic? - Greach 2014, Madrid, Spain

WHERE DO I HAVE TO PUT MY BUSINESS LOGIC?
GRAILS IS NOT MY DOMAIN MODEL.

Greach 2014, Madrid, Spain
Presented March, 28th, 2014

What’s business logic exactly? What’s a domain model? How does the use of a framework like Grails
influence how we build a domain model? How can the use of patterns helps us in building our system?
This talk will approach the problems that we have to face when we put a tool in the core of our
system and we will discuss whether the price we pay for using the Grails framework is too high.

A lot of resources at the end!!

More Decks by Antonio de la Torre Fernández

Other Decks in Programming

Transcript

  1. Where do I put my Business Logic? Antonio de la

    Torre @adelatorrefoss March 28th 2014 Grails is not my Domain Model
  2. Antonio de la Torre @adelatorrefoss Engineer & Agile Coach @

    Kaleidos Madrid, Spain Me
  3. None
  4. A lot of questions & one Proposal

  5. None
  6. None
  7. 1st. step All code inside Controller

  8. Scaffolding helps

  9. Common methods

  10. MVC & Skinny Controller Fat Model

  11. 2nd. step Move to Domain Model

  12. Extra large User

  13. God Object & Services layer

  14. 3rd. step Move to Services

  15. And now XXL Services

  16. Anemic Model & Transaction Script

  17. Problems

  18. Service with too much responsibility

  19. 1.- in Creation complex objects, constraints and invariants

  20. 2.- too much invocations a lot of injected services, no

    separation
  21. 3.- how to save()? addTo, hstore, GORM, mongo, ...

  22. Persistence is a Hardware problem

  23. No OOP

  24. We implement behaviour in Agile

  25. Where is our Business Logic? but …

  26. here it is ...

  27. How looks like our unit tests? mocks & stored data

  28. Actions

  29. Actions Single Responsibility Principle (SRP) SOLID Tell, don’t ask “Object

    Calisthenics. 9 steps to better SW design” , Jeff Bay GRASP
  30. … are all smells

  31. OOP? What about FP?

  32. Functional Programming - Inmutability - Transaction scripts - Stateless services

    - Stateless API - Rare workflows … - Objects with state… but we don’t usually use them “Why OO in web, when usually is DB -> Object -> Process -> Object -> DB” Functional Programming for the Object-Oriented Programmer Brian Marick
  33. So better if we use Agnostic Patterns

  34. Domain Driven Design by Eric Evans DDD

  35. “The goal of domain- driven design is to create better

    software by focusing on a model of the domain rather than the technology”
  36. Tackling complexity DDD is a way of dealing with complexity.

    Complex is easy. Simple is a lot harder.
  37. Ubiquitous Language “A language structured around the domain model and

    used by all team members to connect all the activities of the team with the software”
  38. DDD leads to Model Driven Design

  39. Test your model

  40. Behaviour centric

  41. Layered Arquitecture Diagram

  42. None
  43. None
  44. Entities “When an object is distinguished by its identity, rather

    than its attributes, make this primary to its definition in the model”
  45. Value Objects “When you care only about the attributes of

    an element of the model, classify it as a VALUE OBJECT. Don’t give it any identity…”
  46. Services “When a significant process or transformation in the domain

    is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Make the SERVICE stateless.”
  47. Modules “Choose MODULES that tell the story of the system

    and contain a cohesive set of concepts.”
  48. Aggregates “Cluster the ENTITIES and VALUE OBJECTS into AGGREGATES and

    define boundaries around each. Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only.”
  49. Factories “Shift the responsibility for creating instances of complex objects

    and AGGREGATES to a separate object, which may itself have no responsibility in the domain model but is still part of the domain design.”
  50. Repositories “For each type of object that needs global access,

    create an object that can provide the illusion of an in-memory collection of all objects of that type.”
  51. Implementing

  52. Implementing Entities These are Domain Classes in Grails. They come

    with persistence already resolved through GORM. hasOne vs. belongsTo property can be used to define the lifecycle of entities and their relationships.
  53. Implementing Value Objects In Grails, you can use “embedded” property

    in GORM field to manage a value object. And deal with them with POGO or Command Objects
  54. Implementing Services With our Services in Grails • Dependency Injection

    • Transaction support
  55. Implementing Modules Grails plug-in mechanism.

  56. Implementing Aggregates Aggregates are implemented in the hasMany - belongsTo

    relationship. Can control the root access within a Service.
  57. Implementing Factories Implement Factories classes to create new instances with

    an abstract interface… It could be configurable with properties.
  58. Implementing Repositories Grails Service can be used to implement a

    dedicated Repository object that simply delegates its operation to Grails GORM.
  59. All together

  60. All together … In a more complex Aggregation, create a

    service to manage, this service acts as a Repository. Control invariants. To access a simple Entity use GORM. In a Domain Model with hasOne and belongsTo can act as an Aggregate Root, and use GORM directly. And we reserve Factories to instantiate external providers, like email service, S3 access, push mobile notifications, and so on …
  61. In code ...

  62. Model your domain, create your business logic, and separate it

    from your infrastructure.
  63. Resources Domain Driven Design Eric Evans http://www.slideshare.net/thinkddd/domain-driven-design-dddsydney-2011 - (Intro) Complex

    vs Simple http://pragprog.com/articles/tell-dont-ask - Tell, don't ask http://juan-garcia-carmona.blogspot.com.es/2012/11/solid-y-grasp-buenas-practicas-hacia-el.html - SOLID - Spanish http://www.martinfowler.com/bliki/AnemicDomainModel.html - Anemic Model
  64. Resources http://www.slideshare.net/sergiopolo/introduccin-a-ddd (Spanish) - Building Blocks http://www.slideshare.net/harshjegadeesan/domain-driven-design-presentation STARRED - Intro

    - Building Blocks http://www.slideshare.net/GlenWilson/domain-driven-design-pattern-summaries-presentation - Extense document with Pattern Summaries http://www.slideshare.net/ziobrando/taming-complex-domains-with-domain-driven-design-presentation STARRED!! - Building Blocks - Large Scale DDD
  65. Resources http://www.slideshare.net/DimkaG/domain-driven-design-and-model-driven-development - ideas to implement the building blocks. http://blog.refactoringin.net/2011/08/17/grails-as-a-ddd-platform/

    - Unique reference directly with Grails - Repository??? with GORM… Brian Marick - Functional Programming for the Object-Oriented Programmer https://leanpub.com/fp-oo http://www.mabishu.com/blog/2012/12/14/object-calisthenics-write-better-object-oriented-code/ Object Calisthenics Write Better OO Code Javier Acero - Mi dominio es mio y no lo comparto http://vimeo.com/69157481 (Spanish)