how to organize your business code

1. Business Layer Architecture
Arnaud LEMAIRE
@lilobase

2. Business layer ?
this is why you get paid (usually)

3. WHERE TO PUT THE BUSINESS
CODE ?
OK, important business, so…

4. In MVC application

5. In the View ?

6. In the Controller ?

7. Controller I/O are HTTP requests
• Hard to write unit test
• Impossible reuse

8. In the Model ?

9. But what is a model ?
• A persistance Layer (ie: representation of a db
state) ?
• A class to deal with a ressource ?
• Model is the most misunderstanding layer

10. the most misunderstood layer

11. Fat model approach
• People don’t understand what a model is
• Final source code is a bloated God Object
• Break Single Responsibility Principle (SOLID)
• Hard to reuse
• What about isolation ?

12. So… Stop talking about the model
• But about “domain layer” for business things
• And “persistence layer” for database things

13. MVC IS NOT ABOUT A BUSINESS
LAYER !
And, so… where do we put the business code ?

14. Business Layer

15. People thinks its complicated
• Its about:
– Framework
– Services libraries
– [insert other complicated things]

16. its just OOP

17. POJO / POPO / PORO

18. WHAT DOES “GOOD OOP” MEAN ?

19. High cohesion / loose coupling
• High cohesion : SRP
– One reason to change
• Loose coupling : Seams
– Changing implementation
– DIP, EOP, …

20. Vehicle extends Motor

21. Composition over Inheritance
Vehicle
Car Boat
Motor is a part
of and not a
type of

22. Dont use inheritance to decouple
business layer !

23. These things are also inheritance:
• Module/Mixin (ruby)
• Traits (java, python, php)
• Roles (perl)

24. API oriented code
AKA :
• Information hiding
• Open/Close principle
Only high business value methods are available
in the application
- and not the database query layer -

25. LET’S START DECOUPLING
Things are getting real

26. Value object
• Equality on value not on identity
– Identity: Smith ≠ William
– Value: 1€ = 1€ = 1,36$
• Currencies, Ratings, Date, …

27. Entity Object
• Anything that has a unique and separate
existence.
• User, Book, Request, etc.
• Not only persisted data (see Request)
• Hard to have with ActiveRecord (see next
slide)
• Many of the same entities can be grouped
into a Collection Object

28. Repository Object
• Return entity by making complex queries in
the datastore (because db in not only SQL
now)
• Can be a Query Object (especially in the Rails
world)

29. Validation object
• About validation
• Also known as Form object

30. View Object
• Helpers sucks (a lot, really. You know the
SRP…)
• Use domain specific object

31. Policy Object
• About extracting something from the loaded
context
• Like a query but in a collection of entities (or
just one)
• isConnected ?, specific sort, ...

32. Decorator Object
• Useful to add new behavior not directly linked
to the core domain of the class
• Use Wrapper objects for transformation

33. Service Object
• API part of a concept
• High value business part
• Tested !

35. WHERE DO I PUT THIS BUNCH OF
NEW CLASS ?
Yep, but you still didn’t answer the question…

36. In fact… wherever you want
It’s just OOP, remember?

37. OK, two main organizations
• By domain:
– Banking/
Entity/
Bank
Account
Service/
Deposit
• By type:
– Entity
Banking
Bank
Account
Library
Book
Shelf
the domain approach is preferred

38. Warning

39. Lots of pitfalls
• Anemic model
• To many abstraction
• Procedural programming
• Don’t forget « Simple design rules »
• Lots of freedom : second system pitfall

41. Implementation detail handled
through abstraction
• More generic code
Implementation
detail
Abstraction, we
use this layer to
manage code
Storage
FileStorage MemoryStorage
• Don’t forget to test the
contract (ie: interface)

42. Plenty of cool other stuff
• DCI : Data Context Interaction
• EBI : Entity Boundary Interactor
• CQRS : Command Query Responsibility
Segregation
• and soon… IDD : Iteraction Domain Model
(spoiler: this is a MVC for Domain layer)

43. End

44. Wait,

45. TRY TO TDD
IT COULD SAVE YOUR LIFE, REALLY !

46. Thank you!