Scribd
Upload
33 views24 pages

DDD Intro

Uploaded by

frankyfrankyfranky
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
33 views24 pages

DDD Intro

Uploaded by

frankyfrankyfranky
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

Seminar #2

Domain Driven Design - a pragmatic approach with Python tutorial


Creator: Hoang Tuan / OS1
Date: 2020 Nov

1
Context

How to survive when


business change?

2
Agenda

● DDD Introduction
● Clean Architecture
● Labs - Todos App
DDD Introduction
Software development Zoom out

Core activities Paradigms and models

Processes Requirements Agile


Design Engineering Cleanroom
Construction Testing Incremental
Debugging Deployment Prototyping
Maintenance Spiral
V model
Waterfall

Methodologies and frameworks Practices

ASD DevOps DAD DSDM FDD IID Kanban ATDD BDD


Lean SD LeSS MDD MSF PSP RAD CCO CI
RUP SAFe Scrum SEMAT TSP OpenUP UP CD TDD
XP PP SBE
Stand-up
DDD
Definitions
● DDD is an approach to software development for complex needs by
connecting the implementation (of the software) to an evolving
(domain) model
● Domain in the realm of software engineering commonly refers to the
subject area on which the application is intended to apply
● Approach: mean providing principles & patterns
DDD core principles

● Focus on the core domain and domain logic


● Base complex designs on models of the domain
● Constantly collaborate with domain experts, in order to improve the application
model and resolve any emerging domain-related issues
DDD 360 degree
How to apply DDD?
Overall process
Nhào nặn
Bài Domain Ubiq
kiến thức Architecture Code
toán Model Lang
domain Design Design
thực tế
trong
c/s

Design
UX/UI Coding

Software
App
When to use DDD?
Advantages

● Eases Communication
● Better Code
● A Balanced Application (domain vs UX/UI)
Disadvantages

● Requires Robust Domain Expertise


● Additional Efforts Required
● Not suitable for Highly Technical Projects
Clean Architecture
A quick look

● A clean architecture is a layered


architecture & is also a spherical one
● The deeper a layer is in the
architecture, the more abstract the
content is:
○ The inner layers contain
representations of business
concepts
○ while the outer layers contain
specific details about the real-
life implementation
Data flow

● The communication between elements that live in the same layer is


unrestricted
● Talk inwards with simple structures, talk outwards through interfaces:
○ Talk inwards using basic structures provided by the language (thus globally known)
or structures known to those elements
○ Talk outwards using interfaces, that is using only the expected API of a component,
without referring to a specific implementation
Entities Layer

● This is the inmost layer that contains a representation of the domain


models
● The models in this layer are domain model and different from
persistence / database model
○ They are not connected with a storage system
○ They don’t contain methods to dump themselves to JSON strings
○ They are not connected with any presentation layer
Use cases Layer

● This layer contains the use cases implemented by the system (use
cases are the processes that happen in your application, where you use
your domain models to work on real data)
● A use case should be as small a possible: easier to test, understand and
maintain
● Use cases know the entities & each other
External systems

● This part is made by external systems that implement the interfaces


defined in the previous layer
● Examples of these systems can be a specific framework that exposes an
HTTP API, or a specific database
● This layer is where all the details go
Labs
A fiction project - Todos App

● User will be logged in by providing a username (no need password, no need


to register)
● User could manage one or more todo task items
● Each task's state could be as follow: new -> doing -> done
● To stay focused, user could only have 3 doing tasks at a time. But if he has
finished at least 3 tasks in his lifetime usage, he could have up to 5
concurrent doing tasks
● User could delete/remove any task in the list
● No need to manage task creation time
What’s next
Q&A
THANK YOU!

You might also like