Domain Driven Design Through Onion Architecture

19
Domain Driven Design Through Onion Architecture

description

Domain Driven Design with Onion Architecture is a powerful combination of Architecture Patterns that can dramatically improve code quality and can help you learn a great deal about writing "clean" code.

Transcript of Domain Driven Design Through Onion Architecture

Page 1: Domain Driven Design Through Onion Architecture

Domain Driven DesignThrough Onion Architecture

Page 2: Domain Driven Design Through Onion Architecture

Bowling Score Sheet

Page 3: Domain Driven Design Through Onion Architecture

What is Domain Driven Design

• A technique for developing software that focuses on collaboration between technical experts and domain experts.

• The ideas and terms of the domain should be directly reflected by the code through the Ubiquitous Language.

Page 4: Domain Driven Design Through Onion Architecture

Bowling Domain

•Who are the Domain Experts?

•What is the Ubiquitous Language?

Page 5: Domain Driven Design Through Onion Architecture

Bounded Contexts

•Subdivide large domains into smaller contexts.

•Each context can have it’s own ubiquitous language and it’s own model.

•Bounded Contexts may share some domain aspects.

Page 6: Domain Driven Design Through Onion Architecture

Bowling Bounded Contexts

•Scoring•Statistics•Lane Reservation•Sales•Maintenance

Page 7: Domain Driven Design Through Onion Architecture

Traditional Layered Architecture

Presentation

Business/Domain

Data Access

Page 8: Domain Driven Design Through Onion Architecture

Onion Architecture

Core

Domain

API

Infrastructure

Page 9: Domain Driven Design Through Onion Architecture

The Core

• Building blocks used to create the application.

• Not specific to any domain or technology.

• Eg. Lists, Maps, Case Classes, Actors, Lenses

Page 10: Domain Driven Design Through Onion Architecture

The API

• Acts as an entry point to the Domain

• Communicates using Domain terms and Domain objects

• Should be restricted to exposing only immutable objects

• Can access the Core and the Domain but not the Infrastructure

Page 11: Domain Driven Design Through Onion Architecture

Bowling API

• Could include methods like:• Create Game• Add/Remove Player• Get Players• Set Pin State• Skip Player• Set Lane

Page 12: Domain Driven Design Through Onion Architecture

The Domain

• Built out of the building blocks defined in the Core

• Uses Ubiquitous Language

• BUSINESS LOGIC GOES HERE!

Page 13: Domain Driven Design Through Onion Architecture

Bowling Domain

• Domain Terms: Game, Player, Pin, Frame, Strike, Spare

• Out of Context: Pinsetter, Customer, Lane Reservation

• Non Domain Terms: User Interface, Database

Page 14: Domain Driven Design Through Onion Architecture

Domain Building Blocks

• Value Objects• Entities• Aggregate Roots• Repositories• Factories• Services

Page 15: Domain Driven Design Through Onion Architecture

Bowling Aggregate Root

• Candidates: Player, Game

• Which Entities are present in most or all API operations?

• Which Entity if deleted would result in the deletion of some or all other Entities?

Page 16: Domain Driven Design Through Onion Architecture

The Infrastructure

• Contains adapters for various technology concerns including Databases, User Interfaces, External Services etc.

• Has access to all areas of the system (API, Domain, Core)

Page 17: Domain Driven Design Through Onion Architecture

Bowling Infrastructure

• Pinsetter• UI for lane screens• UI for alley staff• Database

Page 18: Domain Driven Design Through Onion Architecture

Wrap Up

• How portable is the Bowling Score Keeper?

• Can it be adapted to other uses with minimal effort?

• Is it tied to the underlying technology?

Page 19: Domain Driven Design Through Onion Architecture