Downloaded 157 times
Uploaded byBoldRadius Solutions
Domain Driven Design Through Onion Architecture
This document discusses Domain Driven Design (DDD) through the lens of Onion Architecture, emphasizing the collaboration between technical and domain experts, and the use of a ubiquitous language in software development. It outlines the bowling domain's bounded contexts such as scoring and lane reservation, along with the architecture components including the domain core, API, and infrastructure. Key concepts include building blocks like entities and value objects, as well as the importance of adaptability in the bowling scorekeeper system.
More Related Content
Similar to Domain Driven Design Through Onion Architecture
Domain Driven Design Through Onion Architecture
- 1. Domain Driven Design Through Onion Architecture
- 2.
- 3. What is DomainDriven 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.
- 4. Bowling Domain •Who are the Domain Experts? • What is the Ubiquitous Language?
- 5. 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.
- 6. Bowling Bounded Contexts • Scoring • Statistics • Lane Reservation • Sales • Maintenance
- 7. Traditional Layered Architecture Presentation Business/Domain Data Access
- 8. Onion Architecture Infrastructure API Domain Core
- 9. The Core •Building blocks used to create the application. • Not specific to any domain or technology. • Eg. Lists, Maps, Case Classes, Actors, Lenses
- 10. 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
- 11. Bowling API •Could include methods like: • Create Game • Add/Remove Player • Get Players • Set Pin State • Skip Player • Set Lane
- 12. The Domain •Built out of the building blocks defined in the Core • Uses Ubiquitous Language • BUSINESS LOGIC GOES HERE!
- 13. Bowling Domain •Domain Terms: Game, Player, Pin, Frame, Strike, Spare • Out of Context: Pinsetter, Customer, Lane Reservation • Non Domain Terms: User Interface, Database
- 14. Domain Building Blocks • Value Objects • Entities • Aggregate Roots • Repositories • Factories • Services
- 15. 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?
- 16. 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)
- 17. Bowling Infrastructure •Pinsetter • UI for lane screens • UI for alley staff • Database
- 18. 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?