Upload
arnaud-lemaire
View
1.975
Download
1
Embed Size (px)
DESCRIPTION
how to organize your business code
Citation preview
Business Layer Architecture
Arnaud LEMAIRE
@lilobase
Business layer ?
this is why you get paid (usually)
WHERE TO PUT THE BUSINESS CODE ?
OK, important business, so…
In MVC application
In the View ?
In the Controller ?
Controller I/O are HTTP requests
• Hard to write unit test
• Impossible reuse
In the Model ?
But what is a model ?
• A persistance Layer (ie: representation of a dbstate) ?
• A class to deal with a ressource ?
• Model is the most misunderstanding layer
the most misunderstood layer
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 ?
So… Stop talking about the model
• But about “domain layer” for business things
• And “persistence layer” for database things
MVC IS NOT ABOUT A BUSINESS LAYER !
And, so… where do we put the business code ?
Business Layer
People thinks its complicated
• Its about:
– Framework
– Services libraries
– [insert other complicated things]
its just OOP
POJO / POPO / PORO
WHAT DOES “GOOD OOP” MEAN ?
High cohesion / loose coupling
• High cohesion : SRP
– One reason to change
• Loose coupling : Seams
– Changing implementation
– DIP, EOP, …
Vehicle extends Motor
Composition over Inheritance
Vehicle
Car Boat
Motor is a part of and not a type of
Dont use inheritance to decouplebusiness layer !
These things are also inheritance:
• Module/Mixin (ruby)
• Traits (java, python, php)
• Roles (perl)
API oriented code
AKA :
• Information hiding
• Open/Close principle
Only high business value methods are availablein the application
- and not the database query layer -
LET’S START DECOUPLING
Things are getting real
Value object
• Equality on value not on identity
– Identity: Smith ≠ William
– Value: 1€ = 1€ = 1,36$
• Currencies, Ratings, Date, …
Entity Object
• Anything that has a unique and separateexistence.
• User, Book, Request, etc.
• Not only persisted data (see Request)
• Hard to have with ActiveRecord (see nextslide)
• Many of the same entities can be groupedinto a Collection Object
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)
Validation object
• About validation
• Also known as Form object
View Object
• Helpers sucks (a lot, really. You know the SRP…)
• Use domain specific object
Policy Object
• About extracting something from the loadedcontext
• Like a query but in a collection of entities (or just one)
• isConnected ?, specific sort, ...
Decorator Object
• Useful to add new behavior not directly linkedto the core domain of the class
• Use Wrapper objects for transformation
Service Object
• API part of a concept
• High value business part
• Tested !
WHERE DO I PUT THIS BUNCH OF NEW CLASS ?
Yep, but you still didn’t answer the question…
In fact… wherever you want
It’s just OOP, remember?
OK, two main organizations
• By domain:
– Banking/Entity/
BankAccount
Service/Deposit
• By type:
– EntityBanking
BankAccount
LibraryBookShelf
the domain approach is preferred
Warning
Lots of pitfalls
• Anemic model
• To many abstraction
• Procedural programming
• Don’t forget « Simple design rules »
• Lots of freedom : second system pitfall
Implementation detail handledthrough abstraction
• More generic code
Implementation detail
Abstraction, we use this layer to
manage codeStorage
FileStorage MemoryStorage
• Don’t forget to test the contract (ie: interface)
Plenty of cool other stuff
• DCI : Data Context Interaction
• EBI : Entity Boundary Interactor
• CQRS : Command Query ResponsibilitySegregation
• and soon… IDD : Iteraction Domain Model (spoiler: this is a MVC for Domain layer)
End
Wait,
TRY TO TDDIT COULD SAVE YOUR LIFE, REALLY !
Thank you!