The Curse of Service Object

Demonstration of why concept of Service Object is meaningless and harmful, and what should you do instead.

1. The curse OF Service objects Ivan Nemytchenko wrocleve.rb 2024
2. Who am I painlessrails.com makefile.site UrbanConnect Setyl 🇬🇧 🇨🇭 Ivan Nemytchenko 🇷🇺→🇷🇸 Twitter: @inemation Github: @inem on Rails since 2006 Small agency owner ex GitLab
3. Who am I and why am I here
4. Service Object is • a very strange, controversial, and harmful abstraction* • that doesn’t make any sense • contradicts with main architecture principles • and doesn’t give you any benefits*
5. Service Object is • a very strange, controversial, and harmful abstraction* • that doesn’t make any sense • contradicts with main architecture principles • and doesn’t give you any benefits* * in long term
6. OOP In pictures
7. Kettle components (objects) small dudes == objects
8. Objects with methods! hands == methods
9. A method number of fi ngers == number of arguments
10. Instance variables Stored inside the brain
11. Instance variables Can be reused later
12. Returning results
13. Private methods
14. Exception
15. Anti-patterns
16. Too many arguments
17. Too many methods
18. Too long methods
19. Too many instance variables
20. Too much conditional logic in methods Swallen arms
21. Too much of everything!!!
22. Classes A spawning platform
23. Classes A spawning platform
24. same topology Object & classes have the
25. Visual representation of code complexity
27. WHAT is SERVICE OBJECT?
28. What do devs say?
30. What do devs say? • Maintainability, avoid code bloat • Single responsibility • More modular • Encapsulates business logic • Easier to test • Keeps your code clean, organized and structured
31. What do developers do?
32. Service Objects in the wild
33. Service Objects in the wild
34. Service Objects in the wild
35. Service Objects in the wild
36. Service Objects in the wild
37. Service Objects in the wild
38. Service Objects in the wild
39. What do we see? • Validation • Calculation • Creation of an entity (mutation) • Business scenario (mutation + notification) • Business scenario (external service + mutation) • Wrapper for external service
40. The Definition of service object They just do stuff
41. Is the a more deep, philosophical idea behind it?
42. What is so service about them?
43. fowler Patterns of Enterprise Application Architecture
44. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic
45. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary
46. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations
47. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects
48. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions
49. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic
50. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic • coordinates responses
51. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic • coordinates responses
52. Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic • coordinates responses
53. Eric Evans Domain-Driven Design
54. Eric Evans Domain-Driven Design Domain Services: • are stateless
55. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity
56. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations
57. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services
58. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services
59. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services • may have side effects
60. Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services • may have side effects
61. Robert martin Clean Code
62. Robert martin Clean Code • service should have well-de fi ned interface
63. Robert martin Clean Code • service should have well-de fi ned interface • can be a single component or composed of several components
64. Robert martin Clean Code • service should have well-de fi ned interface • can be a single component or composed of several components separated by architectural boundaries •
65. Robert martin Clean Code • "service should have well-de fi ned interface” • can be a single component or composed of several components separated by architectural boundaries • Context: SOA and Microservices
66. Robert martin Clean Code • "service should have well-de fi ned interface” • can be a single component or composed of several components separated by architectural boundaries • Context: SOA and Microservices
67. Robert martin Clean Code • "service should have well-de fi ned interface” • can be a single component or composed of several components separated by architectural boundaries • Context: SOA and Microservices • highlights importance of Single Responsibility Principle
68. The message being sent to us Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services • may have side effects Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic Single Responsibility Principle !
69. The message being sent to us Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services • may have side effects Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic Single Responsibility Principle ! 🤔 🫷 🫸
70. Technical services == Application logic? Service Layer consists of Domain Services, which are: • are stateless • named for an activity rather than an entity • represent signi fi cant operations • coordinate domain objects & control transactions • comply with Single Responsibility principle • may have side effects The message being sent to us 🫷 🫸
71. Technical services == Application logic? Service Layer consists of Domain Services, which are: • are stateless • named for an activity rather than an entity • represent signi fi cant operations • coordinate domain objects & control transactions • comply with Single Responsibility principle • may have side effects The message being sent to us 🫷 🫸
72. Our Service Ruler!! Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic 🫷 🫸
73. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
74. ± Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic ?
75. ? Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
76. ± ± Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
77. ± Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
78. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
79. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic
80. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic Sorry, but NO!
81. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic ?
82. What do devs say? Maintainability, avoid code bloat Single responsibility More modular Encapsulates business logic Easier to test Keeps your code clean, organized and structured ? ± ?
83. What is so object about them?
84. Is there a reason why they are shaped like objects?
85. What is so object about them? • encapsulation • inheritance • polymorphism
86. What is so object about them? • encapsulation • inheritance • polymorphism ± 😱
87. What is so object about them? • state? • lifecycle of an object? • multiple instances of a class?
88. What is so object about them? • state? • lifecycle of an object? • multiple instances of a class?
89. What is so object about them? Pretty much nothing
90. What is service object? • It is a technical trick • In the sake of • moving code from controllers? • testing it separately? (±)
91. Serious guys are doing it too
95. Calls another Service
96. BaseService CreateService
97. BaseService CreateService BaseServiceUtility
99. Complexity Grows inward
100. What we see • Proactively stealing controller’s responsibilities • Mixing application logic with domain logic inside service objects
101. What we see • Code doing different types of work go in the same bucket. • Lots of low level code doing different types of work
102. What we see • Code doing different types of work go in the same bucket. • Lots of low level code doing different types of work
103. Validations Complex mutations Interaction with External systems Calculation logic Business rules Business operations Data preparation Caching Response preparation Work with session
104. What we see • Call chains of Services
105. What we see • Inheritance 😱
106. What we see • Over time complexity grows inward
107. What we see • Service Layer becomes responsible for everything • Effectively we have killed ideas of Layered Architecture, Modularity and SRP at this point.
108. The curse • No reason for services to be shaped as objects • Doesn’t match with what Fathers said • Devs do not achieve proclaimed benefits • Opposes ideas of Layered architecture, Modularity and SRP
109. Validations Complex mutations Interaction with External systems Calculation logic Business rules Business operations Data preparation Caching Response preparation Work with session
110. Mutators Business Rules Business Operations
111. Business Operations Mutators Business Rules
112. Business Operations Mutations Business Rules
113. Interaction with external systems Business Rules Business Operations Mutations
114. Business Rules Data preparation, validations Interaction with external systems Business Operations Mutations
115. Services Managers Mutators Business Rules Forms "Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity" - Simon Wardley
116. how do I do it
117. how do I do it and how do I think about it
119. • Long methods are fine • as long as it is the same type of work • and the same level of abstraction
121. • Let’s have its own “shelf” for every type of work done by your app. • Some shelves we do have already
123. • Low level details of complex mutations go into its own Mutator layer • Mutators are just procedures • No need for callbacks • No more half-baked objects in your system anymore
125. • Domain services are business operations • It is just a procedure • But of a high level of abstraction
127. • Keep application logic outside of services • Check permissions outside of service • Only call it with valid params
133. Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects Code of the same level of abstraction
134. Modularity
135. LAYERed ARCHITECTURE
136. Single responsibility principle
137. EASIER to test
138. Services Mutators Models Controller actions
145. Twitter: @inemation Github: @inem Do you still think Service Object was a good idea?