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.
Service
Objects
Evolution
by @andriymosin
1
01
Service Objects benefits
What we trying to solve
04 Existing realizations
G...
01
next
Why use
Service
Objects?
2
next3
1. Atomic operations only
2. Encapsulate all logic
4. Easy to test
3. Easy to manage
5. Best place to put business l...
02
next
What we had
at the
beginning
4
next5
Basic implementation
next6
Usage
next
Service
Unification
7
1. Same action method name in all service objects
2. Only one public method in object
3. Result...
next
And we start our first big refactoring
8
03
next
What we want
to have in our
Service
Objects
9
next
Our needs
10
1. Data Creating
2. Data Updating
3. Combination
4. Validation
5. Callbacks(success, error)
next
Data
create
&
update
11
next
Combi
nation
12
next
Validations
13
1. Input
1. Required
2. Optional
2. Output
1. Required
2. Optional
04
next
Existing
realizations
14
next15
1. Interactor
2. Light Service
3. ActiveInteraction
4. Mutations
05
next
What we have
for now
16
next
Own implementation
17
with Black Jack and unicorns…
https://github.com/rubakas/cater
next18
First step was to make
architecture and main
decisions about it
1. Modularity
2. Callbacks(success, error)
next19
next20
next21
next22
next23
next24
next
120!!!!!
25
30
60
90
120
150
Jul Sep Jan May
Services Refactoring
next
More services == More refactoring
Refactoring
time
increase
26
next27
Now we have callbacks and
platform for next
experiments
So it’s time for better
error handler and
validations
next
Errors
28
next
“Plan to throw one
(implementation)
away; you will,
anyhow.”
- Fred Brooks
29
next30
Validations
next
Modular implementation with
custom rules
31
next32
next33
next34
next
Virtus
35
next36
next37
Next
Milestone
next38
next39
close
Thank
YouPresenter: Andriy Mosin
http://moxa.io/
@andriymosin
Upcoming SlideShare
Loading in …5
×

Service Objects Evolution

439 views

Published on

Slides for Ruby Meditation 9

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Service Objects Evolution

  1. 1. Service Objects Evolution by @andriymosin 1 01 Service Objects benefits What we trying to solve 04 Existing realizations Gems, best practices and ideas 03 What we want Unification, Validation, Combinations, etc. 02 What we had Pretty basic object 05 What we have for now Our current realization
  2. 2. 01 next Why use Service Objects? 2
  3. 3. next3 1. Atomic operations only 2. Encapsulate all logic 4. Easy to test 3. Easy to manage 5. Best place to put business logic 0. MVC is not enough
  4. 4. 02 next What we had at the beginning 4
  5. 5. next5 Basic implementation
  6. 6. next6 Usage
  7. 7. next Service Unification 7 1. Same action method name in all service objects 2. Only one public method in object 3. Result should always be true || false 4. No ‘returns’ inside Service Objects
  8. 8. next And we start our first big refactoring 8
  9. 9. 03 next What we want to have in our Service Objects 9
  10. 10. next Our needs 10 1. Data Creating 2. Data Updating 3. Combination 4. Validation 5. Callbacks(success, error)
  11. 11. next Data create & update 11
  12. 12. next Combi nation 12
  13. 13. next Validations 13 1. Input 1. Required 2. Optional 2. Output 1. Required 2. Optional
  14. 14. 04 next Existing realizations 14
  15. 15. next15 1. Interactor 2. Light Service 3. ActiveInteraction 4. Mutations
  16. 16. 05 next What we have for now 16
  17. 17. next Own implementation 17 with Black Jack and unicorns… https://github.com/rubakas/cater
  18. 18. next18 First step was to make architecture and main decisions about it 1. Modularity 2. Callbacks(success, error)
  19. 19. next19
  20. 20. next20
  21. 21. next21
  22. 22. next22
  23. 23. next23
  24. 24. next24
  25. 25. next 120!!!!! 25
  26. 26. 30 60 90 120 150 Jul Sep Jan May Services Refactoring next More services == More refactoring Refactoring time increase 26
  27. 27. next27 Now we have callbacks and platform for next experiments So it’s time for better error handler and validations
  28. 28. next Errors 28
  29. 29. next “Plan to throw one (implementation) away; you will, anyhow.” - Fred Brooks 29
  30. 30. next30 Validations
  31. 31. next Modular implementation with custom rules 31
  32. 32. next32
  33. 33. next33
  34. 34. next34
  35. 35. next Virtus 35
  36. 36. next36
  37. 37. next37 Next Milestone
  38. 38. next38
  39. 39. next39
  40. 40. close Thank YouPresenter: Andriy Mosin http://moxa.io/ @andriymosin

×