Good architecture allows you to defer decisions to later.
A good architect maximizes the number of decisions not made.
Popular code separations
- N-Layered Architecture
- Domain Driven Design
- Hexagonal ( Ports and Adapters )
- Onion Arch.
- Clean Arch.
- BCE
- DCI
Framerworks
- Never implement on a class from framework, which make our code couple with the framework.
- Create a interface and use it like a plugin instead.
- DI is need to abstracted to entry level layer, we might need to avoid explicit DI of framerworks in our business layer.
MVC
- Is a delivery pattern.
- The business application doesn’t know anything about the MVC
Cross Cutting Concerns
- Treating CCC
- Infrastructure.
- Domain
- Decorators
(Wrappers)
ORM Can i use ORM ?
Use Case Layer (Business layer) (Interactor)
- Are application specific business rules.
- Which on instansiation accepts a gateway
(of its boundary type)
to work.- Boundaries
(interfaces)
are defined by(for) use case layer.. - The gateway
(impl of boundary)
is expected to implement by(for) the data layer. - Which makes swap of data layer easy, thus achieves loose coupling.
- Boundaries
- Where do we put these second, lower level business rules? In the Entity object. The Interactor tells the Entity what to do.
Boundaries
- Boundaries are interfaces.
- Being defined by Business layers.
Entities
- Application independent business rules.
- There may be many entities involve in a particular use case
(user event)
DAO - Repositories (Adapters)
- It lies on the outer most layer.
- Which acts as a plugin to the use case layer.
- Web is an IO channel, and there is no need for our soruce architecture to show as for WEB.
- Service layer is need to be use case driven.
References