domain driven design from theory to practice
Download
Skip this Video
Download Presentation
Domain-driven design from theory to practice

Loading in 2 Seconds...

play fullscreen
1 / 37

Domain-driven design from theory to practice - PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on

Domain-driven design from theory to practice. Artur Trosin. Presentation for: Software as Craft 2009, 14-16 May. Before start. Why DDD nowadays?. Automation of various business domains High competition for a market place Growing business complexity Complexity becomes inevitable .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Domain-driven design from theory to practice' - nile


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
domain driven design from theory to practice

Domain-driven designfrom theory to practice

Artur Trosin

Presentation for: Software as Craft 2009, 14-16 May

why ddd nowadays
Why DDD nowadays?
  • Automation of various business domains
  • High competition for a market place
  • Growing business complexity
  • Complexity becomes inevitable
why ddd
Why DDD?
  • Accidental complexity is bad
  • DDD is OO done right
  • Semantics over technology
  • Is discovered and NOT invented
ddd benefits
DDD benefits?
  • Reduced complexity
  • High maintainability
  • Continuous collaboration and feedback
  • Brings to front the “Core Domain Knowledge”
  • Translations are reduced to minimum
complexity of most software projects is understanding the business domain and not a technical one
Complexity of most software projects is understanding the business domain and not a technical one.
they are two different worlds
They are two different worlds!

Business Domain

(business experts)

Software Development

(development team)

We need to bring them together

(business domain & technical)

Successes depends on “how well you bring them together”

we need common view and language
We need common view and language!

Software Development

BusinessDomain

DomainModel

&

Ubiquities Language

domain model is a rigorously organized and selective abstraction of the business domain knowledge
Domain Model- is a rigorously organized and selective abstraction of the (Business) Domain knowledge.
slide15

Ubiquitous Language - A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

ubiquitous language
Ubiquitous Language

Business terms

developers don’t

understand

Technical terms

Domain Model Terms

Technical aspects

of design

DDD Patterns

Technical design

patterns

Business terms

everyone uses that

don’t appear in design

Bounded Contexts

S.O.L.I.D design

principles

Candidates to fold into model

collaboration
Collaboration

Domain Experts and Developers produce Model

Software Development

BusinessDomain

Produce

DomainModel

&

Ubiquities Language

Software

Reflected in

Based on

Direct mapping between business domain concepts and software artifacts

classic layering
Classic Layering

UI

Record Sets or

Data Sets or

POCO or

POJO

Business Entities

Data Access

DB

ddd recommended layering
DDD recommended-Layering

Service Layer

UI

UI

Application

Domain Model

Domain

Infrastructure

Infrastructure

Service Getaways

organizing domain logic patterns
Organizing Domain Logic Patterns

Transaction Script

Table Module

Effort

to enhance

Domain Model

Complexity of Domain Logic

Source : PoEAA by Martin Fowler

slide22

A model expressed in software with:

Life Cycle of domain object controlled by:

Repository

Services

Modules

Access with

Access with

Entities

Maintain integrity with

Express model with

Express model with

Express model with

Act as root of

Aggregates

Model-Driven Design

Express model with

Value Objects

Encapsulate with

X

Isolate domain with

Encapsulate with

Encapsulate with

Mutually exclusive

choice

Layered

Architecture

Encapsulate with

Factories

Smart UI

associations
Associations

Country

Country

Country

Period

President

President

President

*

*

*

Person

Person

Person

entities
Entities
  • An object defined primarily by its identity and not its attributes
  • Could be a person, a customer, an order, etc.
  • Not all objects have meaningful identities…
  • In some systems, a class may be an ENTITY, in others maybe not
value objects
Value Objects
  • Represent an aspect of the domain with NO conceptual identity
  • Use when you care about what something is, not who they are
  • Simple, immutable objects
  • NOT is same thing as a DTO [Fowler PoEAA]
services
Services
  • An operation offered as an interface that stands alone in the model
  • Does not fit into any of the objects in the model
  • Stateless
  • To be used judiciously (do not turn your app into a Transaction Script)
  • Use when an operation is an important domain concept
modules
Modules
  • Is larger grain of modeling and design
  • A method of organized related concepts
  • Low coupling and high cohesion
  • Communications mechanism.
  • Could be Administration, Invoicing, Reports,…
aggregates
Aggregates
  • A cluster of associated objects that is treated as a conceptual whole
  • Define consistency boundaries
  • A unit for the purpose of data changes
  • Is controlled by root
factories
Factories
  • Shifts complicated object creation to FACTORY
  • Enforce invariants
  • Decouple clients and hide creation details
repositories
Repositories
  • Provide illusion of an in-memory collection
  • Provide a simple model for obtaining persistent objects
  • Decouple domain model from persistence technology
  • Communicate design decisions about object access
  • IS NOT just DAO with CRUD
collecting basic requirements
Collecting Basic requirements
  • Book cargo in advance
  • Track key handling of customer cargo
ad