The document discusses where to place business logic in an MVC application. It argues that the business layer should not be placed in the view or controller, as those deal with user interface concerns like HTTP requests. The model is also not a good fit, as it is often misunderstood and can become a bloated "God object" that violates principles like single responsibility. Instead, it recommends creating separate classes for business logic following object-oriented principles like high cohesion and loose coupling. These could include value objects, entity objects, repositories, validation objects, view objects, policy objects, decorators, and service objects. It also discusses organizing these objects either by domain or type. Finally, it notes some pitfalls to avoid and

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!