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!