A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
Tonight I presented on Domain Driven Design to the Alt.Net group in Sydney at the invite of Richard Banks.
As a follow up, attached are the slides I used, feel free to distribute and use on the Creative Commons Licence
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Deconstructing Monoliths with Domain Driven DesignVMware Tanzu
SpringOne Platform 2017
David Turanski, Pivotal; Rohit Sood, Liberty Mutual; Rohit Kelapure, Pivotal; Justin Stone, Liberty Mutual
This session will detail a synthesis of techniques used to destroy a monolithic BPM and orchestration based application at Liberty Mutual into an event driven microservices based architecture implemented with Event Sourcing and CQRS. The transformation and developer productivity affected by the monolith decomposition and alignment of business capabilities to bounded contexts teaches lessons for all enterprises looking to undergo similar changes.
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
Domain-Driven Design is an approach to modelling business complexity explicitly in your software. This deck of slides runs through the key concepts focusing on both the strategic and tactical aspects of DDD.
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Some slides, as presented during EKON20 conferences, about the mORMot Open Source project, a Delphi/FPC professional framework featuring highly integrated SOA, MVC, ORM, SOLID over SQL and NoSQL databases.
EKON20 Conference, November 2016
Starting from Michael C. Feathers “Working Effectively with Legacy Code”, we will introduce the concept of “technical debt”, and some practical patterns to integrate testing, separation of concerns, structure, re-usability, to ease maintenance and evolution of existing projects. Don’t forget that even new projects will soon become legacy… Of course, we will introduce some mORMot features which were developed to reduce your pain in this process.
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
Tonight I presented on Domain Driven Design to the Alt.Net group in Sydney at the invite of Richard Banks.
As a follow up, attached are the slides I used, feel free to distribute and use on the Creative Commons Licence
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Deconstructing Monoliths with Domain Driven DesignVMware Tanzu
SpringOne Platform 2017
David Turanski, Pivotal; Rohit Sood, Liberty Mutual; Rohit Kelapure, Pivotal; Justin Stone, Liberty Mutual
This session will detail a synthesis of techniques used to destroy a monolithic BPM and orchestration based application at Liberty Mutual into an event driven microservices based architecture implemented with Event Sourcing and CQRS. The transformation and developer productivity affected by the monolith decomposition and alignment of business capabilities to bounded contexts teaches lessons for all enterprises looking to undergo similar changes.
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
Domain-Driven Design is an approach to modelling business complexity explicitly in your software. This deck of slides runs through the key concepts focusing on both the strategic and tactical aspects of DDD.
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Some slides, as presented during EKON20 conferences, about the mORMot Open Source project, a Delphi/FPC professional framework featuring highly integrated SOA, MVC, ORM, SOLID over SQL and NoSQL databases.
EKON20 Conference, November 2016
Starting from Michael C. Feathers “Working Effectively with Legacy Code”, we will introduce the concept of “technical debt”, and some practical patterns to integrate testing, separation of concerns, structure, re-usability, to ease maintenance and evolution of existing projects. Don’t forget that even new projects will soon become legacy… Of course, we will introduce some mORMot features which were developed to reduce your pain in this process.
EKON20 WorkShop, November 2016
The Open Source mORMot framework is a huge set of units, with a lot of features. It allows Delphi and FPC to eb true competitors for business projects. In this workshop, we will present how its ORM leverages SQL and NoSQL databases, and how interface-based services ease SOA development. We will show some several cross-cutting features, like SynTests (and stubs/mocks), SynLog, SynMustache, SynDB, SynMongoDB, SynSM, SynPDF, SynCrypto or SynEcc. High-level presentation of the involved concepts will always be followed by some sample code.
EKON20 Conference, November 2016
Monolithic rich Windows applications are not enough for our customers. We are often requested to provide a web front-end, or a REST server to be consumed by mobile or thin clients. Integrating n-Tier architecture to an existing project is challenging. Some good practices, based on industry standards and proven design patterns (like uncoupling or SOLID) can be mind-breaker for RAD developers. In this session, we will define some architectural aspects of SOA, ORM and MVC/MVVM, and what our Open Source mORMot framework offers to ease this transition.
A Performance Comparison Of C# 2013, Delphi Xe6, And Python 3.4 Languagesijpla
C# 2013, Delphi XE6, and Python 3.4 are the newest and most popular programming languages. These
programming languages become more popular every passing day. In this study, the response times,
memory usages, and code lengths of these languages were tested in various workloads. Whether or not
there was any significant difference between the data obtained from workloads was tested via the Friedman
test. The test indicated a significant difference. In addition, the Wilcoxon signed rank test was used for
determining the effect size. This test showed that the level of the significant difference found in the
Friedman test was high
Delphi ORM SOA MVC SQL NoSQL JSON REST mORMotArnaud Bouchez
Slides published for BeDelphi 2014 Event.
Create high performance Client Server ORM SOA REST MVC applications using Open Source Synopse mORMot framework and Delphi. Publish any SQL or NoSQL database content over JSON or XML: SQLite3, PostgreSQL, Oracle, MSSQL, FireBird, MongoDB. Define RESTful services using interfaces. Create MVC web applications, using Mustache templates. Running under Windows or Linux, with VCL/FMX clients on Mac OSX, Android or iOS/iPhone/iPad, or AJAX/PhoneGap.
This workshop focuses on domain driven design and how to achieve it effectively. It also focus on bridging gaps while gathering requirements from business stakeholders using event storming workshops.
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
The importance to be Driven
There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.
Présentation sur le Domain-Driven Design par Gérard Dethier (Guardis) aux Geeks Anonymes le 10 novembre 2017.
Vidéo de la conférence : https://youtu.be/OmrtGo68E6M
One of the main advantages of PHP is that it allows you and your company to build up projects in no time and with immediate feedback and business value. Sometimes, however, fast growth and unprevented complexities could make your codebase more and more difficult to manage as time passes and new features are added.Domain Driven Design can be an elegant solution to the problem, but introducing it in mid-large sized projects is not always easy: you have to deal with difficulties at technical, team and knowledge levels. This talk focuses on how to approach the change in your codebase and in your team mindset without breaking legacy code or stopping the development in favor of neverending refactoring sessions.
2015.01.09 - Writing Modern Applications for Mobile and WebMarco Parenzan
Traditional programming is quite old (60+ years)
Object Oriented Programming is not so old, but old enough (35+ years)
We can say that OOP is able to satisfy our needs of Modern programming
Modern is not about modern programming principles and paradigms
Modern is about current scenarios in which our programming abilities have to be spent these days
Just 10 years ago (in 2K years) we were focusing on something else
Modern Programming for about modern programming challenges:
- Cloud
- Big Data
- Mobile and Devices
- Internet of Things
Principles
- Application Lifecycle Management
- Scrum
- Maintainable Code
Imperative Modeling
- Don’t tell what you want to do: just do it!
Responsibility Modeling
- Why are you coding? Which is the intention inside every line you write?
Functional Modeling
- Declare what you need! I’ll implement it!
Object Modeling
- Classes are the way to describe model into a domain
Contract Modeling
- Class is not just encapsulation. It’s also declaration of a contract
Interface Modeling
- Class should be implementation only. Interfaces are a better way to describe a contract
Three tier Modeling
- An Architectural model for an application
“Blueprints” Modeling
- Feel free to express yourself…or not? Please refer to some work done by experts!
“No more One” Modeling
- One model DOES NOT FITS for all. Multiple models are needed to single aspects of an application
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
As a follow-up of the previous session about TFB, we will discuss what kind of tuning was made to the mORMot library, and its associated TFB sample implementation, to reach the top scores in charts. How can a pure Pascal project reach 7 millions of HTTP requests per seconds? How to scale and measure on high-end hardware? Are ORM frameworks damned to slow down everything? How to circumvent the lack of “async” programming at language level? How realistic is such a benchmark?
The TFB challenge is a performance comparison of many web app platforms, exercising JSON, database, ORM, HTML templates, all over HTTP. It compares the best frameworks written in C++, Rust, Go, JS, Java, C#… and now Pascal – thanks to mORMot. In this session, we will look and compare the source code of some frameworks samples, to distinguish their typical philosophy. We will see how modern Object Pascal is still relevant, and propose some ideas for the future of the language.
The most powerful way of writing REST services is to define them via interfaces, then let the SOA/REST framework do all the routing, data marshalling and communication behind the scenes. One distinctive feature of mORMot is to define a method parameter as a notification interface, and let the server call back the client when needed, as with regular Delphi code. This session will present the benefit of defining REST services using interfaces, and how WebSockets can offer real-time notifications into your rich Delphi client applications.
The OpenSource mORMot framework has a strong set of cryptography features. It offers symmetric cryptography with hashing and encryption, together with asymmetric cryptography via private/public key pairs. Its optimized pascal and assembly engines can be embedded into your executable, but you could also call an external OpenSSL library if needed. This session will present mormot.crypt.* units, and apply them to some use cases, from low-level algorithms to high-level JWT or file encryption and signing.
During the continuous mORMot refactoring, some core part of the framework was rewritten. In this session, we propose a journey to a refactoring of a single loop. It will take us from a naïve but working approach, to a 10 times faster Pascal rewrite, and then introduce how SSE2 and AVX2 assembly could boost the process even further – to reach more than 30 times improvement! No previous knowledge of assembly is needed: we will try to introduce how modern CPUs work, and will have some fun with algorithms and SIMD parallelism.
The OpenSource mORMot is a RESTful ORM / MVC / SOA framework for Delphi and FreePascal. Some of its codebase is now about 10 years old, and it was time to clean and evolve. This year 2020 triggered a deep refactoring of the whole source code, with a full rewrite of some core components (JSON, RTTI). This session will present the version 2 of mORMot it its current state, the principles behind this refactoring, and how you may find useful gems for your own Delphi applications.
Ekon23 (2) Kingdom-Driven-Design applied to Social Media with mORMotArnaud Bouchez
To illustrate the “Kingdom Driven Design” session proposal, we will expose and comment upon the software core of a custom social media service. It will create a network of user-generated content, not only connected around people or topics, but unleashing some reference text material: literature, law, science, religion – you name it. We will discuss proper KDD architecture, data structures, and associated microservices, using mORMot’s ORM and SOA as toolbox. The code of this new social media system will be disclosed under a GPL agreement, and running on production for years to come. It should be able to scale from a few users to worldwide adoption.
After years working on Domain-Driven Design projects using Delphi for server-side processes, I eventually followed some kind of cut-back version of the DDD paradigms. Introducing Kingdom Driven Design (aka KDD) – since in biology “Kingdom” is the second highest taxonomic rank, just after “Domain”. We will present some principles to help writing not-database-centric code, without being bloated by all the DDD requirements.
Let your Kingdom come!
High Performance Object Pascal Code on Servers (at EKON 22)Arnaud Bouchez
This EKON 22 conference is about high performance on servers, written in the object pascal (Delphi / FPC) language. Profiling should be the first step to avoid premature optimization, which is the root of all evil (Knuth). But when some bottlenecks are identified, we introduce some simple architecture patterns (like caching or microservices), data structures and algorithms to make process actually faster, with minimal refactoring. It was a fun session about how to write faster code, ending up by looking at the Delphi CPU view – even if you don’t know assembly.
This EKON 22 conference was not about the code formatting - where we put the “begin” keyword is mostly a matter of taste and convention. But it shows how the object pascal strong typing system, and its language expressiveness may help writing clean(er) code. Abstract SOLID principles could help define the class and services hierarchy. After years of server-side coding, we propose some practical guidelines for cleaner object pascal programming, to reduce technical debt, and allow cross-platform/cross-compiler support.
SOLID principles should better be applied when designing business objects, as soon as maintainability and modularity are needed. They bring uncoupling, abstraction and clean design to Object Oriented Programming. Microservices could be seen as SOLID principles applied to the Service Oriented Architecture. In respect to a classical monolith server, thanks to uncoupling and better granularity, you may enhance deployment, ease cooperation between dev teams, introduce Domain Driven Design and/or Event Driven Design, scale horizontally and still incorporate existing code and services.
After a quick and practical review of SOLID principles, we will see how they may apply to SOA, and how Microservices could be defined using the Open Source mORMot framework interface-based services, on Windows or Linux.
Server side process does react to business events. User actions, timers, other services may trigger states of change, which should be tracked and propagated. A classical implementation is to define a shared database or centralized message queue, locally or in the cloud. When applied to Microservices, this monolithic approach will quickly appear as a limitation.
In this session, we will introduce how Microservices could have their own dedicated persistence layer (i.e. database), and how real-time callbacks could be used to leverage real-time propagation of events, without any centralized message queue. Both ORM and SOA features of the Open Source mORMot framework will illustrate how to write such stand-alone services.
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
A Comprehensive Look at Generative AI in Retail App Testing.pdfkalichargn70th171
Traditional software testing methods are being challenged in retail, where customer expectations and technological advancements continually shape the landscape. Enter generative AI—a transformative subset of artificial intelligence technologies poised to revolutionize software testing.
Globus Connect Server Deep Dive - GlobusWorld 2024Globus
We explore the Globus Connect Server (GCS) architecture and experiment with advanced configuration options and use cases. This content is targeted at system administrators who are familiar with GCS and currently operate—or are planning to operate—broader deployments at their institution.
Experience our free, in-depth three-part Tendenci Platform Corporate Membership Management workshop series! In Session 1 on May 14th, 2024, we began with an Introduction and Setup, mastering the configuration of your Corporate Membership Module settings to establish membership types, applications, and more. Then, on May 16th, 2024, in Session 2, we focused on binding individual members to a Corporate Membership and Corporate Reps, teaching you how to add individual members and assign Corporate Representatives to manage dues, renewals, and associated members. Finally, on May 28th, 2024, in Session 3, we covered questions and concerns, addressing any queries or issues you may have.
For more Tendenci AMS events, check out www.tendenci.com/events
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...informapgpstrackings
Keep tabs on your field staff effortlessly with Informap Technology Centre LLC. Real-time tracking, task assignment, and smart features for efficient management. Request a live demo today!
For more details, visit us : https://informapuae.com/field-staff-tracking/
Software Engineering, Software Consulting, Tech Lead.
Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Security,
Spring Transaction, Spring MVC,
Log4j, REST/SOAP WEB-SERVICES.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
Into the Box Keynote Day 2: Unveiling amazing updates and announcements for modern CFML developers! Get ready for exciting releases and updates on Ortus tools and products. Stay tuned for cutting-edge innovations designed to boost your productivity.
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxrickgrimesss22
Discover the essential features to incorporate in your Winzo clone app to boost business growth, enhance user engagement, and drive revenue. Learn how to create a compelling gaming experience that stands out in the competitive market.
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Anthony Dahanne
Les Buildpacks existent depuis plus de 10 ans ! D’abord, ils étaient utilisés pour détecter et construire une application avant de la déployer sur certains PaaS. Ensuite, nous avons pu créer des images Docker (OCI) avec leur dernière génération, les Cloud Native Buildpacks (CNCF en incubation). Sont-ils une bonne alternative au Dockerfile ? Que sont les buildpacks Paketo ? Quelles communautés les soutiennent et comment ?
Venez le découvrir lors de cette session ignite
Enhancing Project Management Efficiency_ Leveraging AI Tools like ChatGPT.pdfJay Das
With the advent of artificial intelligence or AI tools, project management processes are undergoing a transformative shift. By using tools like ChatGPT, and Bard organizations can empower their leaders and managers to plan, execute, and monitor projects more effectively.
Accelerate Enterprise Software Engineering with PlatformlessWSO2
Key takeaways:
Challenges of building platforms and the benefits of platformless.
Key principles of platformless, including API-first, cloud-native middleware, platform engineering, and developer experience.
How Choreo enables the platformless experience.
How key concepts like application architecture, domain-driven design, zero trust, and cell-based architecture are inherently a part of Choreo.
Demo of an end-to-end app built and deployed on Choreo.
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamtakuyayamamoto1800
In this slide, we show the simulation example and the way to compile this solver.
In this solver, the Helmholtz equation can be solved by helmholtzFoam. Also, the Helmholtz equation with uniformly dispersed bubbles can be simulated by helmholtzBubbleFoam.
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Enterprise Resource Planning System includes various modules that reduce any business's workload. Additionally, it organizes the workflows, which drives towards enhancing productivity. Here are a detailed explanation of the ERP modules. Going through the points will help you understand how the software is changing the work dynamics.
To know more details here: https://blogs.nyggs.com/nyggs/enterprise-resource-planning-erp-system-modules/
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Mind IT Systems
Healthcare providers often struggle with the complexities of chronic conditions and remote patient monitoring, as each patient requires personalized care and ongoing monitoring. Off-the-shelf solutions may not meet these diverse needs, leading to inefficiencies and gaps in care. It’s here, custom healthcare software offers a tailored solution, ensuring improved care and effectiveness.
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
D2 domain driven-design
1. Software Architecture & Design
Architecture
From n-Tier to SOA
From SOAP to REST
Technical Debt
Design
From SQL to ORM, NoSQL and ODM
From RAD to MVC
SOLID principles
Domain Driven Design (DDD)
Applying patterns on Delphi code using mORMot
Software Architecture & Design
5. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
6. Domain Driven Design
Focus on the Domain
Define Bounded contexts within this domain
Create an evolving Model of the domain
Use Ubiquitous Language in model and code
Identify objects: Values, Entities, Aggregates
Publish the domain as well-defined Services
Isolate the domain from other kind of concern
Uncouple from implementation details
Integrate the domain services with existing
Domain Driven Design
7. DDD pre-requisites
Identified and well-bounded domain
e.g. your business target should be clearly identified
Access to domain experts
need iterative creative collaboration
Skilled team, able to write clean code
more about code expressiveness than technology
You want your internal team to accumulate
knowledge of the domain
therefore, outsourcing may be constrained
to applications, not the core domain
Domain Driven Design
8. Role of Patterns
In your code: once: it’s a fluke, twice: its
coincidence, three times: it’s a Pattern!
Discovered (observed), not invented
Except for their name
Elevate effectiveness of our communication
A ‘shorthand’ for more complex ideas
Domain Driven Design
9. DDD: the premise
Writing software is actually straightforward
Determining what to write is hard!
The Key to success is understanding
the Problem Domain intimately
Not to use the latest shiny technology
Domain Driven Design
10. Check your concerns
You have a specific problem to solve
Your goal is identified , but your business is exploring
You do not know how to accomplish your goal
You need to bring clarity, and solve inner complexity
e.g. modeling a lot of rules
DDD is not to build simple applications – RAD is there
DDD meets your strategic goals
DDD is to be used where you will get your business
money, and make you distinctive from your competitors
You don't have all of these, but at least one or two
Domain Driven Design
11. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
12. Ubiquitous Language
Developers and Business People
move in different worlds
have different languages to express their ideas
the other 10th kind of people
how do not know about binary…
use company- or industry-standard terminology
Domain Driven Design
14. Ubiquitous Language
Language should be Ubiquitous
In classes, methods, variables, even in tests
Behavior-Driven Development
Conversing using the same language
‘Solution smells’ detected by Domain Experts
Discovery of new domain concepts by developers
Shared learning by all involved
Model must evolve: always remove ambiguities
Domain Driven Design
16. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
17. Modeling a Domain
What do we call Domain here?
The domain represents a sphere of knowledge,
influence or activity
As a result
The domain has to be clearly identified
Your software is expected to solve a set of
problems related to this domain
You may have several domains to modelize
Domain Driven Design
18. Modeling
DDD is some case of Model-Driven Design
Its purpose is to create a model
of a given domain
The code itself will express the model:
as a consequence, any code refactoring means
changing the model, and vice-versa
Domain Driven Design
19. Modeling
Be honest: reality is just too big
Modeling is about filtering the reality
for a given use context
“All models are wrong, some are useful”
G. Box, statistician
Several models may coexist for a given reality,
depending of the knowledge level involved
what we call a Bounded Context
Domain Driven Design
20. Modeling
Bounded Context
Organize your code between bounded contexts
Most objects and services will be specific
to each context, tuned to each model
Some objects (or parents) may be reused
in the same domain (but not between domains)
Ubiquitous language applied
Consistent naming between the contexts
Proper namespace / units use
Domains and Contexts appear in source code folders
Domain Driven Design
21. Modeling
Bounded Context
The same reality will appear several times
in several models
Don't be afraid if the same reality is defined several
times in your domain code, one class for each context
Always specify your current modelization context
Just as in Google Maps the zoom level or the kind of
map shows several models of the same world
Domain Driven Design
22. Modeling
Modeling is about forgetting the details
Focus on the essentials
Given an objective knowledge level
Specific to a bounded context
Domain Driven Design
23. Modeling
Model State
Static
To abstract a given state of the reality
Dynamic
To abstract how reality evolves (i.e. its behavior)
Changes are mostly continuous in reality
Dynamic modeling will create
static snapshots of the reality (called state transitions)
It will embrace the deterministic nature of computers
Domain Driven Design
24. Modeling
State brings complexity
It is a fact we won’t argue
So our code should be as stateless as possible
Some patterns
Try to always separate value and time in state
Reduce statefulness to only the necessary
Implement your logic as state machines
instead of blocking code or sessions
Persistence should handle one-way transactions
Domain Driven Design
25. Modeling
DDD expresses static model state using
Immutable Value Objects
To define a static value
Entity Objects (or Entities)
To refer to a given state of given identity
For instance, the same identity (named "John Doe") may
be, at a given state, single and minor, then, at another
state, married and adult. The model will help to express
the given states, and the state transitions between them
(e.g. John's marriage)
Domain Driven Design
26. Modeling
DDD expresses dynamic model state
Via Factory / Repository / Unit Of Work patterns
Code will get given state of the model
Then process its domain knowledge
And return the new state
Via Events
When a system does change its state very often
Events may be the core of the domain
See Event-Driven Design or Event Sourcing
Domain Driven Design
27. Modeling
To express the modularity of the model
Partitioning
the more your elements have a separated concern,
the better, since the model will be more stateless
we will create a lot of objects (interface segregation)
not abuse of inheritance
are you focusing on the domain, or on your code?
Grouping
to express constraints, elements may be grouped
usually, no more than 6/8 elements per diagram
Aggregate Root to group objects to model constraints
Domain Driven Design
28. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
29. Value Objects and Entities
Model-level structures
Reduce the model into objects or structured types
May be class or record
Make the implicit explicit
Naming should follow the Ubiquitous language
Define dedicated types
e.g. a TPhoneNumber instead of plain string/RawUTF8
Use dynamic structures like TDocVariant
Especially during initial exploring phase
Or to pass opaque infrastructure information
Domain Driven Design
30. Value Objects and Entities
Model-level representation will define
Value Objects
contain attributes (value, size)
but no conceptual identity
e.g. money bills, or seats in a Rock concert
Entity objects
are not defined by their attributes (values),
but their thread of continuity, signified by an identity
e.g. persons, or seats in most planes, as each one is
unique and identified.
Domain Driven Design
31. Value Objects and Entities
Value objects are immutable by definition
So should be handled as read-only
They are incapable of change once they are
created
Seeking side-effect-free functions
concept borrowed by DDD to functional languages
Domain Driven Design
32. Value Objects and Entities
Entities will very likely have an ID field
To identify a given reality
To model the thread of continuity of this identity
But this ID is an implementation detail
Only used at Persistence Layer level
At Domain Layer level, data access via an
Aggregate Root, linked to a bounded context
May be hidden by CQRS statefull services
Query an aggregate, then apply Commands
Domain Driven Design
33. Value Objects and Entities
Aggregates are a particular case of Entities
Defined as collection of objects
nested Values and/or Entities
That are grouped together by a root Entity
otherwise known as an Aggregate Root
which scope has been defined by execution context
Allow composition (or grouping) in the model
For persistence, are the transactional boundary
May be NoSQL, or at least via ORM
Domain Driven Design
34. DTO & Events
Isolate the domain from the outer world
Value Objects may be used with no translation
So may be used as DTO classes
Even Entities may be transmitted directly
Since their methods should not refer to anything but
their internal properties
In short: be realistic/lazy, but paranoid
Better isolate your domain with DTO types
To increase maintainability and efficiency
Domain Driven Design
35. DTO & Events
Data Transfer Objects (DTO)
are transmission objects
to avoid leaking the Domain objects across the wire
Anti-Corruption Layer i.e. separate your layers
Create gatekeepers that to prevent
non-domain concepts from leaking into your model
Even public API should use adapters
Domain Driven Design
36. DTO & Events
Commands and Events
are some kind of DTO
since they communicate data about an event
and they themselves encapsulate no behavior
in mORMot, interface types e.g. over Websockets
or via master/slave replication of simple tables
Domain Driven Design
37. Factory & Repository
Factory pattern
is used to create class instances
In strongly-typed OOP (like in Delphi, Java or C#),
this pattern is in fact its constructor method and
associated class type definition, which will define a
fixed set of properties and methods at compilation
not as e.g. in JavaScript or most other script languages
is used to create interface instances
see SOLID principles (mainly Liskov substitution)
Domain Driven Design
38. Factory & Repository
Repository pattern
used to save and dispense each Aggregate Root
Can use e.g. TSQLRecord “Layer Supertype”
ORM / CRUD interface
Or dedicated repository classes
Dedicated interfaces (may be CQRS but not anemic)
Following Ubiquitous domain language (not CRUD pattern)
Saving data is a concern orthogonal to the model
DDD architects claim that
persistence is infrastructure, not domain
Domain layer should be abstracted (via IoC)
Domain Driven Design
39. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
40. Services
Aggregate roots’ methods
Aggregate roots are the only kind of entities
to which your software may hold a reference
Tend to be the main access point of any process
from the application layer point of view
Often end up as state machines
with all their methods
It could be handy to
publish those methods as stateless Services
isolated at Application layer level
Domain Driven Design
41. Services
Domain services
are used to model primary operations
i.e. publish tools for modeling processes
that do not have an identity or life-cycle in your domain
that is, that are not linked to one particular aggregate root,
perhaps none, or several
In this terminology, services are not tied to a particular
person, place, or thing in the application, but tend to
embody processes
Main rule is to let the Domain layer
focus on the business logic
Domain Driven Design
42. Services
Domain services
Named after verbs or business activities
That domain experts introduce into Ubiquitous Language
Should be exposed as client-oriented methods
Following Interface segregation principle
As a reusable toolbox: do not leak your domain!
Application layer services
Would use the Domain Services
To implement the needs of client applications
Domain Driven Design
43. Services
Unit Of Work
Can be used to maintain a list of objects affected by
a business transaction
Coordinates the writing out of changes
and the resolution of concurrency problems
Persistence Ignorance or Database agnosticism
At application layer level
Implements transactions for Domain entities and services
May be implemented by ORM to “hydrate” Aggregate roots
class instances as abstractly as possible
Domain Driven Design
44. Domain Driven Design
Domain Driven Design
Model-Driven
Design
Ubiquitous
Language
define
model with
Bounded
Contexts
identify
scope with
Services
process
model with
Entities
express
model with
Value Objects
express
model with
Clean/Layered/
Hexagonal
Architecture
isolate
domain with
Events
express state
changes with
RAD
exclude
Repositories
access with Aggregates
encapsulate with
Factories
instantiated by
encapsulate with
instantiated by
access with instantiated by
45. Clean / Layered Architecture
Domain Driven Design
DDD 4-tier layered architecture
Presentation Layer
Application Layer
Domain Layer
Business Layer
and cross-cutting / vertical layer
With proper isolation of the Domain layer
To focus on the domain
To not let the domain be polluted
by technical stuff, application particularities…
47. Clean DDD architecture
From the physical point of view
N-layered DDD architecture
Domain Driven Design
Layer Description
Presentation MVC UI generation and reporting
Application Services and high-level adapters
Domain Model Where business logic remains
Data persistence ORM and external services
Cross-Cutting Horizontal aspects shared by other layers
48. Clean DDD architecture
From the physical point of view
Still looks like a classic 4-tier layered design
But DDD does its best
to isolate the Domain Model
from any dependency
Abstract from technical details
Do not be tied to the application layer
To modelize a “clean” architecture
Domain Driven Design
50. Clean DDD architecture
From the logical point view
Onion-like more than layered-like
Domain at the core
Should stay as stable as possible
Stay as uncoupled as possible
Define domain objects
Value Objects, Entities, Aggregate Roots
Define domain services consumed outside
Define abstract services implemented outside
e.g. persistence interface
Domain Driven Design
51. Clean DDD architecture
From the logical point view
Onion-like more than layered-like
Application services layer
Will change very often and evolve a lot
Typical workflow:
Dehydrate Aggregate Roots using persistence service
Call the Domain services
Call external services, commit persistence (Unit of work)
Domain Driven Design
52. Clean DDD architecture
From the logical point view
Onion-like more than layered-like
Presentation services layer
For each end-user application
Depending on each technology (VCL, HTML, AJAX)
Infrastructure services layer
Persistence depending on database (SQL/NoSQL)
External services (SOA)
Tests with stubs and mocks
Regression and integration tests are part of the design
Domain Driven Design
53. Clean DDD architecture
Clean, since it controls coupling
Coupling is toward the center
All code can depend on layers more central
But cannot depend on layers further out from the core
This architecture is unashamedly biased toward OOP,
which puts objects before all others
Relies on the Dependency Inversion principle
Uses interface for behavior contract
Force the externalization of infrastructure
Domain Driven Design
54. Clean DDD architecture
Clean, since it is upside-down
Database is not the center of your logic
Nor the bottom of your physical design
Database is external
There is no such “database application” in DDD
As any other third-party service
Favor isolation between layers
Via dedicated adaptor services
Domain Driven Design
56. DDD commitments
I shall collaborate with domain experts
I shall focus on using our ubiquitous language
I shall not care about technical stuff or framework,
but about modeling the Domain
I shall make the implicit explicit
I shall use end-user scenarios to get real and concrete
I shall not be afraid of defining one model per context
I shall focus on my Core Domain
I shall let my Domain code be uncoupled from any external influence
I shall separate values and time in state
I shall reduce statefulness to only the necessary
I shall always adapt my model as soon as possible,
once it appears inadequate
Domain Driven Design
58. DDD & mORMot
DDD may be implemented with mORMot
Value objects
as record and dynamic arrays
or TSynPersistent / TSynAutoCreateField class
Entities (and Aggregate Roots)
as TSynAutoCreateField class
and mORMotDDD.pas TDDDRepositoryRestFactory
or directly – but not preferred – as TSQLRecord
Data Transfer Objects as record or TDocVariant
Depending if the schema is fixed or variable
Domain Driven Design
59. DDD & mORMot
DDD may be implemented with mORMot
Services as interface-based services
At Domain or Application layer
To be accessed locally or remotely
Security, Asynchronous Callbacks (Websockets)
Services as method-based services
At Domain layer, for Aggregate root methods
At Application layer, for publishing REST services
Domain Driven Design
60. DDD & mORMot
DDD may be implemented with mORMot
Persistence as TSQLRest or dedicated service
With TSQLRestBatch as Unit-Of-Work
Advanced mapping via mORMotDDD.pas
TDDDRepositoryRestFactory
Command Query Segregation Services (CQRS)
mORMotDDD.pas ICQRSQuery ICQRSCommand
Dual-phase commit for SOA orchestration
Domain Driven Design
61. DDD & mORMot
DDD may be implemented with mORMot
Desktop Applications User Interface
With optional auto-generation of the layout
Including grids, i18n and interaction with the VCL
Web Applications User Interface
AJAX over REST/SOA
Web using MVC/Mustache
Code-driven reporting
Data from ORM/SOA objects, not TDataSet
Integrated preview and PDF export
Domain Driven Design
62. DDD & mORMot
DDD may be implemented with mORMot
Services/daemons abstract classes
Thread-based or process-based daemons
Integration as Windows Services or Linux Daemons
Settings, console, monitoring, remote administration
All cross-cutting features are available
Filtering/validating, security, cache, logging
JSON, transmission, RTTI, tests, stubs/mocks
Domain Driven Design
63. Domain Driven Design
Presentation
Application
Data persistence
Domain
Model
Cross-Cutting
AJAX
REST Client
REST Server
HTTP 1.1
Cache
UI
i18n
Filtering
Validation
Reporting
ORM
Services
(interface-based)
Security
Sessions
SQLite3
External DB
Value Objects
as record
Entities
as TSQLRecord
Aggregates
as TSQLRecord
Tests
Mocks/Stubs
Logging