This document provides an introduction to domain-driven design (DDD). It defines DDD as an approach where the application's domain model reflects the real business domain and core domain is the primary focus. It discusses DDD principles like ubiquitous language, domain encapsulation, and technical simplicity. The benefits of DDD include improved communication through a shared language, a modular and extensible domain model, and the domain rules and logic being encapsulated in one place.
Domain Driven Design main concepts
This presentation is a summary of the book "Domain Driven Design" from InfoQ.
Here is the link: http://www.infoq.com/minibooks/domain-driven-design-quickly
Domain Driven Design main concepts
This presentation is a summary of the book "Domain Driven Design" from InfoQ.
Here is the link: http://www.infoq.com/minibooks/domain-driven-design-quickly
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.
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
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.
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
Presentation describes Domain Driven Design - approach to create applications driven by business domain. I show how to split your monolith base on DDD strategic patterns.
The domain model is an abstraction of the problem domain that your system supports. It contains the objects and operations that are crucial to your system and its users. Therefore the design of the domain model deserves the utmost care and attention. In this session you will be introduced to Domain-Driven Design and you will learn how to put Domain-Driven Design (DDD) into practice. We will explore how to apply DDD on tactical level to design a rich domain model that encapsulates behaviour, protects its invariants and can be tested in isolation from its runtime environment
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.
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.
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.
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
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.
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
Presentation describes Domain Driven Design - approach to create applications driven by business domain. I show how to split your monolith base on DDD strategic patterns.
The domain model is an abstraction of the problem domain that your system supports. It contains the objects and operations that are crucial to your system and its users. Therefore the design of the domain model deserves the utmost care and attention. In this session you will be introduced to Domain-Driven Design and you will learn how to put Domain-Driven Design (DDD) into practice. We will explore how to apply DDD on tactical level to design a rich domain model that encapsulates behaviour, protects its invariants and can be tested in isolation from its runtime environment
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.
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.
In building large scale web applications MVC seems like a good solution in the initial design phase. However after having built a few large apps that have multiple entry points (web, cli, api etc) you start to find that MVC breaks down. Start using Domain Driven Design.
Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.[1] The premise of domain-driven design is the following:
Placing the project's primary focus on the core domain and domain logic.
Basing complex designs on a model of the domain.
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Have more questions?
Twitter: @wajrcs
Web: http://waqaralamgir.tk
The first day slides of the Domain Driven Design course that I imparted on Schibsted Spain.
They talk about technical debt, domain modeling, model driven design and SOLID principles.
An Introduction to Domain Driven Design in PHPChris Renner
We use PHP to solve problems. But as software projects grow and the business needs increase, how do we manage the complexity and still produce readable and maintainable code? Domain Driven Design is a set of concepts and practices that, when applied appropriately, help us manage complexity in large scale projects. In this talk, we will explore the broad points of DDD. I’ll also share tips, patterns and lessons-learned gained from my experiences building PHP software for complicated business processes.
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...confluent
Designing and Implementing Information Systems with Event Modeling, Bobby Calderwood, Founder at Evident Systems
https://www.meetup.com/Saint-Louis-Kafka-meetup-group/events/273869005/
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...confluent
"Event Modeling is a fairly new information system modeling discipline created by Adam Dymitruk that is heavily influenced by CQRS and Event Sourcing. Its lineage follows from Event Storming, Design Thinking, and other modeling practices from the Agile and Domain-Driven Design communities. The methodology emphasizes simplicity (there are only four model ingredients) and inclusion of non-developer participants.
Like other modeling disciplines, Event Modeling is sufficiently general to enable collaborative learning and knowledge exchange among UI/UX designers, software engineers and architects, and business domain experts. But it's also sufficiently expressive and specific to be directly actionable by the implementors of the information system described by the model.
During this talk, we'll:
* Build an Event Model of a simple information system, including wire-framing the UI/UX experience
* Explore how to proceed from model to implementation using Kafka, its Streams and Connect APIs, and KSQL
* Jump-start the implementation by generating code directly from the Event Model
* Track and measure the work of implementation by generating tasks directly from the Event Model"
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
Abstract:
This talk introduces definitions of system architecture and proposes a way to achieve "good enough" architecture covers project requirements
Andrei will show several cases from real projects, where wrong, missing or over-sophisticated architecture decisions really hurt the development teams:
Painful sharing: do shared modules increase reusability or will be the source of problems?
Non-extensible extensibility: too sophisticated configuration hurts
Over fine-grained: incorrect splitting to microservices can make life even harder as with monolith
Cargo cult: blindly following patterns and rules can produce an unmaintainable system
Freestyle architecture: what happens if teams completely ignore architecture
Improve with less intelligence: smart endpoint and dumb pipes
We are looking forward to meet many of you in person and have great discussions around this topic!
https://www.meetup.com/de-DE/meetup-group-tfyvuydp/
How can Oracle Forms (or other legacy) applications be modernized to fit in a contemporary IT architecture? Trends, concepts and technologies are discussed.
Model-driven and low-code development for event-based systems | Bobby Calderw...HostedbyConfluent
It's a dream as old as business computing: the ability to create a graphical model and then to deploy it as a working information system. Many attempts to realize this dream have come and gone with varying degrees of success, from visual programming languages like Visual Basic and Scratch, to business workflow systems like BPMN and its proprietary commercial variants, to engineering-focused systems like UML.
But let's face it: most low-code and model-based application development tools fall far short of the needs of modern software development teams. At best, they're useful for rapidly testing ideas and creating prototypes. At worst, they're used by "citizen coders" to cynically circumvent good engineering practices, with IT operations left holding the bag of operating, securing, and scaling black-box applications that cut against modern DevSecOps practices.
Event-driven application architecture, enabled by infrastructure like Kafka and its ecosystem, has the potential to dramatically advance toward the age-old, model-driven and low-code dream. But what would an event-centric and developer-friendly low-code look like?
This talk will outline strategies for low-code and model-driven development based on Event Modeling. We'll explore how event-driven application architecture provides a simple yet robust framework for generating DevSecOps-friendly code for the UI, for the web services layer, and for event-processing.
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
Abstract
The idea of this talk is to help development teams to make correct architectural decisions.
Andrei will highlight the basic architectural principles and show ways to achieve architecture that is good enough to cover the project requirements and evolve in the future.
He will also present several cases from real projects, where wrong, missing, or over-sophisticated architecture decisions really hurt the development teams:
- Painful sharing: do shared modules increase reusability or will be the source of problems?
- Microservices are the solution to every problem!
- Non-extensible extensibility: too sophisticated configuration hurts
- Over fine-grained: incorrect splitting to Microservices can make life even harder as with monolith
- Convey horizontal split: how organizational driven split can jeopardise the architecture
- Model-driven: central responsibility blocks and limits the team
- Cargo cult: blindly following patterns and rule can produce an unmaintainable system
- Freestyle architecture: what happens if teams completely ignore architecture
- Improve with less intelligence: smart endpoint and dumb pipes
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven DesignNETFest
“Domain Driven Design is an approach to software development for complex needs by connecting the implementation to an evolving model.”
While there are many resources on the web about the DDD, they are generally theoretical rather than useful practical guides. One reason is that a DDD implementation quite varies depending on your domain and culture. However, it is still possible to provide some explicit rules those can help you while designing your code base.
This talk starts by introducing the DDD and providing a layering model based on the DDD and the Clean Architecture. It then introduces the core building of an application built on the DDD principles.
In the second part of the talk, it shows some strict coding rules for the core building blocks with real code examples and suggestions. These rules are essential to build a large scale application implements DDD patterns & practices.
While the solution structure and code samples are based on .NET and C#, the talk is useful for developers and architects working with any server side technology.
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...Dell World
Moving from infrastructure-centric IT to efficient, software-driven private or hybrid cloud requires more than gluing together knobs and gears. In addition to the infrastructure considerations, special attention needs to be paid to tying business workflows and organizational processes to IT processes to optimize application delivery and increase productivity for your users and customers. How you approach cloud-building to make it really usable by the business is the key to success.
Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)Bojan Veljanovski
In this talk I want to share with you an alternative way to develop .NET applications in a more modular way by embracing emergent design techniques. The main idea is to decompose your application into small and reusable modules, in order to achieve high maintainability, low technical debt and prevent the ‘Big Ball of Mud’ creeping in. But how to succeed with this?
Come to my session and you’ll gain a whole new way of thinking about programming, reasoning and designing great software.
Beyond Software Craftsmanship - Johnny's Road to Remarkable CareerEduards Sizovs
Meet Johnny - a full-stack Java developer with 5+ years of experience under the belt, M.Sc degree and 'get sh%t done fast' mentality. Although Johnny possesses exceptional technical skills, Milton - his manager, doesn't promote him, no matter how hard Johnny tried and how many late nights he has spent polishing his coding skills. Unfortunately, there is something important that Johnny doesn't understand. Something that stops him from becoming successful. Together with Johnny, you will walk the thorny road to his remarkable career as a Chief Software Architect. The road full of struggles, discoveries and actions that may or will influence your professional life.
8 Things That Make Continuous Delivery Go NutsEduards Sizovs
Continuous Delivery is still trendy and everyone wants to get there, but there are so many walls you have to break and nerves to spoil! In this talk Eduards will present real-world battle stories of continuous delivery adoption, 10 underlooked things that tend to go wrong and what practices can you apply in order to survive.
Software developers spend most of their time working with code on literal level. Unfortunately, vast amount of design flaws hides behind hundreds of interrelated packages, classes and methods, destroying your system deliberately. In this talk will supply you with knowledge necessary to manage complexity of your logical design from theoretical, practical and tooling perspectives. Time to keep architecture in predictable and manageable state!
Applications of different size, business domain and criticality suffer from a huge set of issues, be it boring enterprise software, “Highly-Loaded” social network or a cozy startup. In this talk Eduards will cover Software Architecture issues that he finds the most prevailing nowadays and what you can do with that. Think big!
Are you doing all you can to further your career as a software developer? With today's rapidly changing and ever-expanding technologies, being successful requires more than technical expertise. In this talk Eduards outlines the practices used by software craftsmen to maintain their professional ethics and simple Dos and Don'ts for teams who want to be considered professional craftsmen.
2. Speaker
Eduards Sizovs
Software Architect at 4finance
- linkedin/in/eduardsi
- eduards.sizovs@gmail.com
3. Agenda
• What is DDD
• Principles
• Benefits
• Why people do not use DDD
• Building blocks
• How to start
4. What is DDD
• DDD – approach to developing software where
application’s domain model reflects real business
model and core domain is the primary project focus
domain.compareTo(technology) > 0
5. Close creative collaboration
• Team + Domain Experts works together
• Chaotic info is transformed into practical model
• Model is continuously distilled and refined
• It’s not just quizing for requirements
7. UL example (user story)
• Bad: When user logs in using valid data, his
active credits are displayed
• Good: When borrower logs in using valid
credentials, his open loans are displayed
8. Example
• User user = userFactory.newInstance();
• userService.register(user);
• Application application;
• Loan loan = loanService.takeCredit(application, user);
• if (loan != null) { ...
User user = userFactory.newUser();
user.register();
LoanApplication application;
Loan loan = user.applyForLoan(application);
if (application.rejected()) …
9. Natural refinement
If sophisticated can easily
That way we domain experts
do notweaknesses in the
find understand the model,
there is something wrong with
domain model
the model
10. Domain encapsulation
• Focus on specific business operation (e.g. Loans)
• Isolation from other domains (Loans from Credit
Bureau)
• Isolated from other layers (UI, integration)
• Loose coupling with external dependencies (anti-
corruption layer)
12. Domain’s richness
• Domain is a rich model of entities, relations, rules
and conditions, not just a data carrying entities
13. Benefits
• Ubiquitous Language in communication, requirements,
specification, domain model, tests
• Common model that the team can use to communicate about
business requirements
• The model is modular, extensible and easy to maintain
• Business model is encapsulated in one place
• Model is easy testable based on real business scenarios
• Final Code = Domain specification
14. If you do not follow DDD
• Likely you will have a fat service layer with anemic
domain model
• Domain rules and business logic are scattered in
many helpers and facades
• Harder to react to business requirement changes
• Communication is difficult
16. Anemic Domain Model
• Common architectural anti-pattern
• Violates basic OO principle – encapsulation
• “Service-driven DTOs”
17. Why people do not use DDD
• Complex component model with layering
enforcements (EJB 2.*)
• Easier to grasp with development with no prior
analysis (ad hoc development)
• Adapted to anemic domain model
• No access to domain experts
• No iterative development process
• Unwillingness to understand new domains
• Lack of good examples
18. Why people do not use DDD
• Clinging to technical things and frameworks
• DDD requires good OOA&D skills
• Thinking in terms of Computing
20. Entity
• An object defined primarily by its identity
• May have multiple representations
• Distinguished from another entity even both might
have the same attributes
• Example: Customer, Book, Vehicle
• Example: Two deposit transactions
21. Value Object
• An object having no identity and defined by its
attributes
• Describes state of entities
• Really powerful when built immutable
• Example: Money, Time
• Example: GPS program returns Route connecting
Boston and Rhode Island entities
22. Module (or package)
• Contains cohesive set of concepts
• Coevolves with a model
• Speaks UL
• When you place some classes together in a module,
you are telling next developer to think about them
together
23. Stadium seat example
• If visitors can sit wherever they find an empty seat
then seat is a...
• If visitors buy a ticket with a seat number on it, then
seat is a...
24. Aggregate
• A collection of objects that are bound together by a
root entity. The aggregrate root guarantees the
consistency of changes being made within the
aggregate by forbidding external objects from
holding references to its members
25. Repository
• A contract between application and data storage,
that speaks UL
• Pretends to be a collection of Aggregate Roots
• Repository is persistence ignorant
26. Example
• Payment Schedule comprises of Regular Installments
• Client pays-off Regular Installments
• Payment Schedule must be closed when all Regular
Installments get paid
• Payment Schedule gets processed according to client
payments
27. Factory
• Methods for creating domain objects should
delegate to a specialized Factory
• Helps when entity creation is complicated or reveals
its internal structure
• Decouples object creation from other layers
28. Service
• When an operation does not conceptually belong to
an Entity nor to a Value Object you can put it in a
service
• Services are still a natural part of a model
• Domain services should be distinguished from other
services (application, infrastructural)
29. Events
• Event captures a change to the model so different
model components can observe these changes and
react accordingly