An Introduction to Domain Driven Design focusing on the concepts of Bounded Context, Strategic & Tactical Design, CQRS, Ubiquitous Language, Hexagonal Architecture, Event Sourcing, Task - based UIs
- DDD is designed around an onion architecture for loose coupling between domains, applications, and infrastructure
- Event storming helps gather structured information to understand the business domain and requirements
- Entities have unique IDs and are mutable while value objects describe entities and are immutable
- Aggregates group related entities and value objects together, with the root entity accessible from outside
- Invariants, anti-corruption layers, and domain events help model the business logic and handle changes
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
The document discusses strategies for transitioning from a monolithic architecture to microservices, including splitting a monolith based on business domains and functional areas. It explains tactical patterns from Domain-Driven Design like bounded contexts, ubiquitous language, and context mapping that can help structure microservices and define integration points. The document also provides additional resources on Domain-Driven Design patterns and strategies for applying them when developing microservice architectures.
Domain-Driven Design (DDD) is an approach to software development that prioritizes the core domain and domain logic. It advocates building a shared understanding of the domain through a ubiquitous language and modeling the domain concepts and entities. The document outlines the key concepts and building blocks of DDD such as bounded contexts, entities, value objects, aggregates, repositories, and factories.
This document provides an overview of domain-driven design (DDD). Some key points:
- DDD is an approach to software development that focuses on modeling the core domain and problem domain. It aims to create software that is tailored to the needs of its domain.
- When using DDD, developers work closely with domain experts to develop a domain model through knowledge crunching techniques. This domain model serves as a shared language between technical and business teams.
- The domain model is separated from technical concerns. Multiple bounded contexts may be defined to decompose large domains. Code is developed to closely align with the domain model.
- Patterns like entities, aggregates, and repositories are used tactically but D
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.
The document discusses Domain Driven Design (DDD), a software development approach that focuses on building an object-oriented model of the domain that software needs to represent. It emphasizes modeling the domain closely after the structure and language of the problem domain. Key aspects of DDD discussed include ubiquitous language, bounded contexts, entities, value objects, aggregate roots, repositories, specifications, domain services, modules, domain events, and command query separation. DDD is best suited for projects with a significant domain complexity where closely modeling the problem domain can help manage that complexity.
- DDD is designed around an onion architecture for loose coupling between domains, applications, and infrastructure
- Event storming helps gather structured information to understand the business domain and requirements
- Entities have unique IDs and are mutable while value objects describe entities and are immutable
- Aggregates group related entities and value objects together, with the root entity accessible from outside
- Invariants, anti-corruption layers, and domain events help model the business logic and handle changes
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
The document discusses strategies for transitioning from a monolithic architecture to microservices, including splitting a monolith based on business domains and functional areas. It explains tactical patterns from Domain-Driven Design like bounded contexts, ubiquitous language, and context mapping that can help structure microservices and define integration points. The document also provides additional resources on Domain-Driven Design patterns and strategies for applying them when developing microservice architectures.
Domain-Driven Design (DDD) is an approach to software development that prioritizes the core domain and domain logic. It advocates building a shared understanding of the domain through a ubiquitous language and modeling the domain concepts and entities. The document outlines the key concepts and building blocks of DDD such as bounded contexts, entities, value objects, aggregates, repositories, and factories.
This document provides an overview of domain-driven design (DDD). Some key points:
- DDD is an approach to software development that focuses on modeling the core domain and problem domain. It aims to create software that is tailored to the needs of its domain.
- When using DDD, developers work closely with domain experts to develop a domain model through knowledge crunching techniques. This domain model serves as a shared language between technical and business teams.
- The domain model is separated from technical concerns. Multiple bounded contexts may be defined to decompose large domains. Code is developed to closely align with the domain model.
- Patterns like entities, aggregates, and repositories are used tactically but D
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.
The document discusses Domain Driven Design (DDD), a software development approach that focuses on building an object-oriented model of the domain that software needs to represent. It emphasizes modeling the domain closely after the structure and language of the problem domain. Key aspects of DDD discussed include ubiquitous language, bounded contexts, entities, value objects, aggregate roots, repositories, specifications, domain services, modules, domain events, and command query separation. DDD is best suited for projects with a significant domain complexity where closely modeling the problem domain can help manage that complexity.
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.
This document discusses domain-driven design (DDD) concepts for transforming a monolithic application to microservices, including:
1. Classifying applications into areas like lift and shift, containerize, refactor, and expose APIs to prioritize high business value, low complexity projects.
2. Focusing on shorter duration projects from specifications to operations.
3. Designing around business capabilities, processes, and forming teams aligned to capabilities rather than technology.
4. Key DDD concepts like ubiquitous language, bounded contexts, and context maps to decompose the domain model into independently deployable microservices.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
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
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.
This document outlines the concepts and techniques of Domain-Driven Design (DDD). It begins with basic concepts like the ubiquitous language and domain model. It then covers strategic design patterns such as bounded contexts and context mapping. Next, it discusses tactical design building blocks like entities, aggregates, and repositories. Finally, it briefly introduces related patterns like CQRS, event sourcing, and event-driven architectures. The document is intended to provide an overview of DDD from basic concepts to advanced patterns in both the strategic and tactical spheres.
The document discusses the principles of clean architecture. It states that clean architecture aims to minimize human effort required to build and maintain software systems. It emphasizes that the core of an application should be its use cases rather than technical details like databases or frameworks. The architecture should clearly communicate the intent of the system. It also notes that dependencies should flow inward from outer layers like interfaces to inner layers containing core business logic and entities.
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.
Domain Driven Design (DDD) is a software development approach that focuses on modeling a complex domain into code. The document discusses key DDD concepts like entities, value objects, aggregates, repositories, bounded contexts, and validation. It provides examples of how these concepts are implemented in code and outlines challenges and situations where DDD may not be appropriate, such as for non-complex domains without behavior/logic or where the data model maps directly to a relational database schema.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
This document provides an introduction and overview of domain driven design (DDD). It defines key DDD concepts like domain, ubiquitous language, bounded context, and domain model. It explains how to apply DDD patterns like layered architecture, entity model, value model, aggregate model, and service model. It also discusses how to unify domain models and implement DDD in practice using techniques like ubiquitous language, bounded contexts, and entity/value/aggregate models. The document aims to help readers understand the problem DDD solves, core DDD principles and patterns, and how to apply DDD on real projects.
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.
Introduction of Kubernetes - Trang NguyenTrang Nguyen
This presentation provides the basic concepts of the Kubernetes for Beginners.
1) Introduction of Kubernetes
Before Kubernetes
What is Kubernetes
What Kubernetes can do?
What Kubernetes can't do?
Features of Kubernetes
Kubernetes Architecture
Kubernetes vs Docker Swarm
Kubernetes 7 use cases
...
2) Kubernetes Component
What is Kubelet?
What is Kubectl?
What is Kubeadm?
3) Nodes in Kubernetes
What is a node in Kubernetes?
Master node
Worker node
4) Kubernetes Development Process
What is blue green deployment?
How to automate the deployment?
5) Networking in Kubernetes
Kubernetes networking model
Ingress networking in Kubernetes
6) Security Measures in Kubernetes
Best security measures in Kubernetes
Introduction to Modern Software ArchitectureJérôme Kehrli
This document provides an overview of modern software architecture models and concepts. It begins with an introduction to software architecture and definitions. It then discusses the Kruchten 5+1 view model for describing architecture using multiple views. Additional topics covered include the OCTO matrix approach, example architecture diagrams for a sample application called RIA Organizer, and modern architectures like big data, microservices and serverless computing.
Introducing Domain Driven Design - codemashSteven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Kevin Huang: AWS San Francisco Startup Day, 9/7/17
Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.
Three Pillars, Zero Answers: Rethinking ObservabilityDevOps.com
Observability has never been more important: the complexity of microservices makes it harder and harder to answer basic questions about system behavior. The conventional wisdom claims that Metrics, Logging and Tracing are “the three pillars” of observability… yet software organizations check these three boxes and are still grasping at straws during emergencies.
In this session, we’ll illustrate the problem with the three pillars: metrics, logs, and traces are just data – they are the fuel, not the car.
DDD Strategic Patterns and Microservices by ExampleErik Ashepa
As Microservices have grown in popularity in recent years and quickly became the preferred method for many developers, more and more teams are facing difficulties integrating and extending them with the high cadence promise they initially delivered.
That was the case a few years ago at Fiverr, the world's largest marketplace for digital services. After adopting a Microservices architecture, development was a breeze compared to the mighty monolith... but once the honeymoon period was over their progress was slowing down as they encountered issues such as:
Losing transactionality inside a service boundary
Unclear data ownership
Intertwined and non business focused services
Dependency graph for deployments
If you feel you are approaching the end of your Microservices honeymoon period, then this talk is for you!
Erik will explain what DDD's Strategic Patterns are and how adopting them helped them to better align their tech with the business, facilitate team autonomy and ownership and most importantly deliver high quality products faster!
Domain-driven design is a collaborative process involving both domain experts and software practitioners. This high-level overview takes a look at the driving principles behind domain-driven design. It also explores domain-driven design's building block patterns, supple design, strategic design, and distillation of the core.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
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.
This document discusses domain-driven design (DDD) concepts for transforming a monolithic application to microservices, including:
1. Classifying applications into areas like lift and shift, containerize, refactor, and expose APIs to prioritize high business value, low complexity projects.
2. Focusing on shorter duration projects from specifications to operations.
3. Designing around business capabilities, processes, and forming teams aligned to capabilities rather than technology.
4. Key DDD concepts like ubiquitous language, bounded contexts, and context maps to decompose the domain model into independently deployable microservices.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
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
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.
This document outlines the concepts and techniques of Domain-Driven Design (DDD). It begins with basic concepts like the ubiquitous language and domain model. It then covers strategic design patterns such as bounded contexts and context mapping. Next, it discusses tactical design building blocks like entities, aggregates, and repositories. Finally, it briefly introduces related patterns like CQRS, event sourcing, and event-driven architectures. The document is intended to provide an overview of DDD from basic concepts to advanced patterns in both the strategic and tactical spheres.
The document discusses the principles of clean architecture. It states that clean architecture aims to minimize human effort required to build and maintain software systems. It emphasizes that the core of an application should be its use cases rather than technical details like databases or frameworks. The architecture should clearly communicate the intent of the system. It also notes that dependencies should flow inward from outer layers like interfaces to inner layers containing core business logic and entities.
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.
Domain Driven Design (DDD) is a software development approach that focuses on modeling a complex domain into code. The document discusses key DDD concepts like entities, value objects, aggregates, repositories, bounded contexts, and validation. It provides examples of how these concepts are implemented in code and outlines challenges and situations where DDD may not be appropriate, such as for non-complex domains without behavior/logic or where the data model maps directly to a relational database schema.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
This document provides an introduction and overview of domain driven design (DDD). It defines key DDD concepts like domain, ubiquitous language, bounded context, and domain model. It explains how to apply DDD patterns like layered architecture, entity model, value model, aggregate model, and service model. It also discusses how to unify domain models and implement DDD in practice using techniques like ubiquitous language, bounded contexts, and entity/value/aggregate models. The document aims to help readers understand the problem DDD solves, core DDD principles and patterns, and how to apply DDD on real projects.
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.
Introduction of Kubernetes - Trang NguyenTrang Nguyen
This presentation provides the basic concepts of the Kubernetes for Beginners.
1) Introduction of Kubernetes
Before Kubernetes
What is Kubernetes
What Kubernetes can do?
What Kubernetes can't do?
Features of Kubernetes
Kubernetes Architecture
Kubernetes vs Docker Swarm
Kubernetes 7 use cases
...
2) Kubernetes Component
What is Kubelet?
What is Kubectl?
What is Kubeadm?
3) Nodes in Kubernetes
What is a node in Kubernetes?
Master node
Worker node
4) Kubernetes Development Process
What is blue green deployment?
How to automate the deployment?
5) Networking in Kubernetes
Kubernetes networking model
Ingress networking in Kubernetes
6) Security Measures in Kubernetes
Best security measures in Kubernetes
Introduction to Modern Software ArchitectureJérôme Kehrli
This document provides an overview of modern software architecture models and concepts. It begins with an introduction to software architecture and definitions. It then discusses the Kruchten 5+1 view model for describing architecture using multiple views. Additional topics covered include the OCTO matrix approach, example architecture diagrams for a sample application called RIA Organizer, and modern architectures like big data, microservices and serverless computing.
Introducing Domain Driven Design - codemashSteven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Kevin Huang: AWS San Francisco Startup Day, 9/7/17
Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.
Three Pillars, Zero Answers: Rethinking ObservabilityDevOps.com
Observability has never been more important: the complexity of microservices makes it harder and harder to answer basic questions about system behavior. The conventional wisdom claims that Metrics, Logging and Tracing are “the three pillars” of observability… yet software organizations check these three boxes and are still grasping at straws during emergencies.
In this session, we’ll illustrate the problem with the three pillars: metrics, logs, and traces are just data – they are the fuel, not the car.
DDD Strategic Patterns and Microservices by ExampleErik Ashepa
As Microservices have grown in popularity in recent years and quickly became the preferred method for many developers, more and more teams are facing difficulties integrating and extending them with the high cadence promise they initially delivered.
That was the case a few years ago at Fiverr, the world's largest marketplace for digital services. After adopting a Microservices architecture, development was a breeze compared to the mighty monolith... but once the honeymoon period was over their progress was slowing down as they encountered issues such as:
Losing transactionality inside a service boundary
Unclear data ownership
Intertwined and non business focused services
Dependency graph for deployments
If you feel you are approaching the end of your Microservices honeymoon period, then this talk is for you!
Erik will explain what DDD's Strategic Patterns are and how adopting them helped them to better align their tech with the business, facilitate team autonomy and ownership and most importantly deliver high quality products faster!
Domain-driven design is a collaborative process involving both domain experts and software practitioners. This high-level overview takes a look at the driving principles behind domain-driven design. It also explores domain-driven design's building block patterns, supple design, strategic design, and distillation of the core.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
The document discusses refactoring code towards a domain-driven design approach. It notes that over time, as more features are added and teams grow, code becomes more complex without design. Domain-driven design is presented as a way to refactor code through techniques like defining a ubiquitous language, identifying domain models, isolating domains with bounded contexts, and expressing state changes with events. Refactoring requires prioritization and "boyscout refactoring" of cleaning up small pieces of code litter. The document advocates for seeing the benefits of refactoring without having to fully adopt every aspect of domain-driven design or drink the "kool-aid." Consistency is important when refactoring.
Why Domain-Driven Design Matters
In the software industry, the life expectancy of ideas, methodologies, and technologies, is extremely short. And yet, after ten years, Domain-Driven Design is still growing bigger. From it’s original roots in OOP, it has now expanded into Functional Programming, Reactive Programming and Event Sourcing, and architectural styles such as Hexagonal and CQRS. Clearly something about Domain-Driven Design makes it such an appealing choice to build systems for complex domains.
In this session, we’ll discuss what DDD is: from design patterns and modelling techniques, to the more philosophical ideas about how we deal with complexity. We explore why it has made such a profound impact, and how to decide whether it’s right for your project. We’ll have lots of room for open discussion, to make sure all your questions are answered.
--
Mathias Verraes is a recovering music composer turned programmer, consultant, blogger, speaker, and podcaster. He advises companies on how to build enterprise web applications for complex business domains . For some weird reason, he enjoys working on large legacy projects: the kind where there’s half a million lines of spaghetti code, and nobody knows how to get the codebase under control. He’s the founder of the Domain-Driven Design Belgium community. When he’s not working, he’s at home in Kortrijk, Belgium, helping his two sons build crazy Lego train tracks.
This document discusses Domain-Driven Design (DDD) and how it can be applied to ASP.NET MVC projects. It covers DDD concepts like ubiquitous language, bounded contexts, entities, value objects, domain services, and domain events. It also discusses how to structure an MVC project to separate the domain model from the rest of the application using patterns like layered architecture and ports and adapters. The document argues that DDD can provide benefits like flexibility, manageable complexity, and centralized business logic, though it may require more time and effort to implement.
This document discusses lessons learned from using Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and Event Sourcing (ES) patterns. It outlines six common problems encountered, such as how to generate unique identifiers and handle event versioning. It also provides examples of approaches to address these issues, including using domain events to track identifier values and migrating event streams during data changes. Overall the document aims to share experiences implementing these architectures to help others applying similar patterns.
La arquitectura basada en componentes se enfoca en descomponer el diseño de un sistema en componentes funcionales o lógicos independientes que interactúan a través de interfaces bien definidas. Este estilo de diseño usa componentes discretos que se comunican mediante métodos, eventos y propiedades, lo que ofrece beneficios como facilidad de instalación, costos reducidos, reusabilidad y mitigación de complejidad.
Domain-driven design is a collaborative process involving both domain experts and software practitioners that attempts to address issues of complexity in software. This process is described in the book Domain-Driven Design (Addison-Wesley 2004) written by Eric Evans. Domain-driven design starts with the assertion that (for almost all software) complexity is in the domain, not in the technology. Accordingly, we must let technology play a supporting role. Domain-driven design attempts to focus on and distill the core domain for a given project.
Philosopher and scientist Alfred Korzybski said, "The map is not the territory." As such, a person practicing domain-driven design does not attempt to model reality. Instead, domain experts and software practitioners use a mental model as a tool for solving problems within a given domain. The domain experts and software practitioners collaborate to explore and develop this model. No software of any reasonable scope has just one model. We will look at the concept of a bounded context within which each model can be isolated and explored. Within a bounded context, collaborators must speak a ubiquitous language in order to reason about and discuss the model.
We will also talk about domain-driven design's building block patterns including entities, value objects, aggregates, repositories, services, and domain events. We will look at domain-driven design practices including supple design, strategic design, and distillation of the core. We will see how test-driven development can be used as a means of exploring the model. Examples in PHP will be provided of the building block patterns as well as other techniques including closure of operations, intention revealing interfaces, side-effect free functions, and assertions.
Domain-Driven Design (DDD) is very useful set of tools to tackle complexity in a software projects. However, many software developers never heard of it, yet most of the one who do emphasize too much on the technical implementation.
This slide will explain what is DDD and why, and also what is its core.
The document discusses CQRS (Command Query Responsibility Segregation) and Event Sourcing application architectures. It begins with an overview of common application architectures like layered architecture and hexagonal architecture. It then explains event-driven architecture and how event sourcing can be used for data storage. CQRS is introduced as separating read and write interfaces. The document contrasts a traditional architecture with one using CQRS and event sourcing together. It provides a code example and concludes with questions and resources for further reading.
An Introduction to Domain Driven Design for Product Managersr4isstatic
A presentation to the BBC Product Management community, introducing the concepts, processes and techniques of Domain Driven Design, including Domain Modelling and URL design. Also talks briefly about the Semantic W
Mapping Problem Domain Objects to Object-Persistence Formats(OOAD)Meenakshi Devi
The document discusses mapping problem domain objects to different object persistence formats, including files, object-oriented databases (OODBMS), object-relational databases (ORDBMS), and relational databases (RDBMS). It provides rules for mapping problem domain classes and relationships like inheritance, aggregation, and association to tables and columns when using an OODBMS, ORDBMS, or RDBMS. Overall, the rules aim to maximize portability of problem domain classes while accounting for limitations of each persistence format, such as lack of inheritance support in ORDBMS and RDBMS.
Agile development and domain driven designJacopo Romei
Agile development is getting every year more popular around the world while a less known methodology is the Domain Driven Design (DDD) which defines a few rules to be followed to empower the agile team to raise communication effectiveness. Agile methods and DDD are perfectly matching and used together can solve many problems we are all too sadly used to.
Modularity and Domain Driven Design; a killer combination?ACA IT-Solutions
Applying domain driven design in a modular fashion has implications on how your data is structured and retrieved.
A modular domain consists out of multiple loosely coupled sub-domains, each having their own modular schema in the database. How can we migrate and evolve the database schema's separately with each new sub-domain version? And how do we match this with reporting and cross-domain use cases, where aggregation of data from multiple sub-domains is essential?
A case study concerning an OSGi-based business platform for automotive services has driven us to solve these challenges without sacrificing the hard-worked-on modularity and loose coupling.
In this presentation you will learn how we used Modular Domain Driven Design with OSGi. 'Liquibase' is elevated to become a first class citizen in OSGi by extending multiple sub-domains with automatic database migration capabilities. On the other hand, 'Elasticsearch' is integrated in OSGi to become a separate search module coordinating cross-domain use cases. This unique combination enabled us to satisfy two important customer requirements. Functionally, the software should not be limited by module boundaries to answer business questions. Non-functionally, a future-proof platform is required in which the impact of change is contained and encapsulated in loosely coupled modules.
Modern business applications rely heavily on rich domain classes, which in turn rely heavily on polymorphic execution, code reuse and similar concepts.
How can we extend rich domain classes to support complex requirements?
In this presentation, Zoran Horvat will show why an object composition approach is favored over class inheritance when it comes to code reuse and polymorphism.
The presentation covers:
How class inheritance can lead to combinatorial explosion of classes
What the limitations of object composition are
What design patterns help consume composed objects
Techniques for creating rich features on composed objects
Watch the webinar recording here: http://www.postsharp.net/blog/post/webinar-recording-object-composition
Domain-driven design is a software development approach that focuses on modeling the core domain and problem space. It values collaboration between developers and domain experts to create a ubiquitous language for discussing the domain. The goal is to develop a deep understanding of the problem and build software that meets the needs of the business domain through an iterative process of learning and modeling.
Success by Challenging Assumptions (Part I)LaDonna Coy
Part one of a two part workshop on Creating Success by Challenging Assumptions with Stephanie Nestlerode, Omega Point International, Inc. and LaDonna Coy, Learning for Change, Inc. for the Texas SPF SIG community grantees. All materials are located at http://bit.ly/xQSu9
Presentation given at "Software for Domain Experts", Athens, Nov 2016. It is about Software for Domain Experts, Domain Driven Design and Systemic Approach. Its purpose is to show how we can follow the Domain Driven Design approach along with the Systemic Approach in order to produce high quality Software for Domain Experts.
This document introduces domain-driven design (DDD) as an approach to tackling complexity in software development. It discusses how DDD draws from concepts like dividing problems into smaller pieces and iterative development. The core of DDD involves collaboratively building domain models through a ubiquitous language within bounded contexts. This helps create a shared understanding between domain experts and software developers. The document provides examples of DDD building blocks like entities, value objects, aggregates, and events. It suggests DDD is best for problems that are complicated, innovative, and high value, where organizations are committed to collaboration between domain and development teams.
This document provides an overview of Stéphane Ducasse's presentation on looking differently at code. The presentation covers: facts about software complexity and maintenance efforts; their approach of using reverse engineering, analyses, and visualizations; their Moose open-source reengineering platform; principles of preattentive visualization; examples of visualizations like distribution maps and class blueprints; and challenges in understanding large and evolving software systems.
This document discusses different approaches to designing software architectures, including methods, creativity, and developing judgment. It outlines an engineering design process and potential problems that can arise. Alternative design strategies like cyclic, parallel, adaptive, and incremental processes are presented. Key concepts of abstraction, separation of concerns, and leveraging experience are emphasized as fundamental design tools. The document also introduces domain-specific software architectures, architectural patterns, and architectural styles as ways to apply lessons learned from prior work. Specific patterns like model-view-controller and sense-compute-control are described, along with an example application to a lunar lander game.
This document provides information about a course on design patterns taught by Dr. Asma Cherif. It includes the course code, instructor details, learning objectives, textbooks, and topics that will be covered such as architectural design, what patterns are, and different types of patterns. Design patterns provide solutions to common software design problems and promote reuse of successful designs. The course aims to help students understand design patterns, identify patterns in code and designs, and implement patterns to design and develop quality software applications.
The document discusses using Domain Driven Design and the Systemic Approach to develop Software for Domain Experts. It proposes that Domain Driven Design, based on simple Systemic principles, can help develop high-value software by focusing on the core domain, collaborating with domain experts to build models of the domain, and establishing a common language within explicit boundaries. The Systemic Approach aids this process by helping to understand and model the domain, its context and dynamics, and uncover patterns of behavior to discover the domain's structure. Together, these approaches aim to develop empathetic software that meets business needs in an agile and differentiated way.
Domain Driven Design (DDD) is an approach to software development that prioritizes domain knowledge. It focuses on building a shared understanding between technical and domain experts through a ubiquitous language. The fundamentals of DDD include modeling the domain, domain objects like entities and value objects, aggregates, repositories, and bounded contexts. Patterns like modules, factories, and specifications help implement the domain model. The goal is clean, knowledge-rich design focused on the business domain.
This document provides an overview and introduction to domain-driven design (DDD). It discusses the core principles of DDD, including focusing on modeling the domain, capturing domain knowledge in software models, and structuring software around domain concepts. The document also summarizes some common DDD patterns and techniques for managing complexity, such as ubiquitous language, layered architecture, aggregates, entities, value objects, services, factories, and repositories. The overall goal of DDD is to build software that is closely aligned with the conceptual model of the problem domain.
This document provides an introduction to design patterns. It begins by explaining what design patterns are, their benefits, and common elements of design patterns like name, problem, solution, and consequences. It then discusses different types of design patterns classified by purpose (creational, structural, behavioral) and scope (class, object). An example of applying the strategy pattern to a duck simulation is used to illustrate how patterns can solve common object-oriented design problems by separating variable aspects from those that remain the same. The document advocates programming to interfaces rather than implementations to avoid tight coupling and allow independent extension of behavior.
SE2_Lec 19_Design Principles and Design PatternsAmr E. Mohamed
The document discusses software design patterns and principles. It defines what design patterns are, their benefits, and some commonly used patterns like Singleton, Observer, and Strategy. It also covers software design principles like the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, and others. The document provides examples to illustrate how patterns and principles can be applied to improve software design.
The document discusses the differences between analysis modeling and design engineering/modeling. Analysis involves understanding a problem, while design focuses on creating a solution. Models can be used to better understand problems in analysis or solutions in design. The key aspects of design engineering are then outlined, including translating requirements into a software blueprint, iterating on the design, and ensuring quality through guidelines such as modularity, information hiding, and functional independence. Common design concepts like abstraction, architecture, patterns, and classes are also explained.
The document discusses key concepts in software design, including:
- Mitch Kapor's "software design manifesto" emphasized good design exhibiting firmness, commodity, and delight.
- Design encompasses principles, concepts, and practices that lead to high quality systems, including data/class design, architectural design, interface design, and component-level design.
- Quality guidelines for design include modularity, distinct representations of elements, appropriate data structures, independent components, and reduced complexity interfaces.
Model-driven framework for Guided Design Space Exploration presented at ASE 2011Ábel Hegedüs
Guided Design-space Exploration using the VIATRA framework (http://viatra.inf.mit.bme.hu/) presented at the ASE 2011 conference (http://www.continuinged.ku.edu/programs/ase/)
The document provides an overview of the Dynamic Reconfigurability in Embedded System Design (DRESD) project. It describes the MicroLAB organization involved in DRESD, various motivations for reconfiguration, definitions of reconfiguration, examples of reconfiguration in everyday life, new frontiers for reconfigurable computing, the DRESD philosophy, involvement of DRESD at Politecnico di Milano and internationally, main DRESD projects, and opportunities to get involved.
SE2018_Lec 18_ Design Principles and Design PatternsAmr E. Mohamed
The document discusses software design patterns. It defines design patterns as general and reusable solutions to commonly occurring problems in software design. It describes the key parts of a design pattern as the pattern name, the problem it addresses, the solution it provides, and the consequences of applying the pattern. The document also outlines some of the benefits of using design patterns such as codifying good design practices and providing a common vocabulary for designers.
The document discusses the design of user interfaces for CAD (computer-aided design) systems. It outlines requirements for CAD interfaces to be comprehensive, flexible, responsive, focused, and accessible. The document then explains the design thinking process and how it was used to develop the interface for a CAD system using the Microsoft Fluent UI framework. Examples are provided of how the interface was customized for different users like emergency call takers, fire brigades, and coast guards.
Developing and deploying AI solutions on the cloud using Team Data Science Pr...Debraj GuhaThakurta
Presented at: Global Big AI Conference, Santa Clara, Jan 2018 Developing and deploying AI solutions on the cloud using Team Data Science Process (TDSP) and Azure Machine Learning (AML)
This document discusses object-oriented design and architectural design. It begins by outlining topics related to determining how to build a system using object-oriented design, including design goals, architectural designs, class modeling, design patterns, state chart modeling, collaboration modeling, and more. It then discusses what software design is, including that it is a problem-solving process to implement functional requirements while meeting non-functional constraints. Design involves making decisions to resolve issues while choosing from design alternatives. The document also discusses top-down and bottom-up design approaches, software design principles, and the object-oriented design process.
Applying DDD and CQRS can not only make the resulting design of our system simpler and more effective but, freeing us from the burdenof the “one model fits all” approach, also allows architects to adopt different strategies when it comes to business logic modeling. Though lot has been written about DDD and CQRS, missing working code publicly available seems to be the elephant in the room: in this talk, we’ll find out how to implement the “Command side of the Force” by means of a proper Domain Model and getting to the point of switching from an entity based modeling to an event based one.
Similaire à Introduction to Domain Driven Design (20)
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
14 th Edition of International conference on computer visionShulagnaSarkar2
About the event
14th Edition of International conference on computer vision
Computer conferences organized by ScienceFather group. ScienceFather takes the privilege to invite speakers participants students delegates and exhibitors from across the globe to its International Conference on computer conferences to be held in the Various Beautiful cites of the world. computer conferences are a discussion of common Inventions-related issues and additionally trade information share proof thoughts and insight into advanced developments in the science inventions service system. New technology may create many materials and devices with a vast range of applications such as in Science medicine electronics biomaterials energy production and consumer products.
Nomination are Open!! Don't Miss it
Visit: computer.scifat.com
Award Nomination: https://x-i.me/ishnom
Conference Submission: https://x-i.me/anicon
For Enquiry: Computer@scifat.com
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
UI5con 2024 - Boost Your Development Experience with UI5 Tooling ExtensionsPeter Muessig
The UI5 tooling is the development and build tooling of UI5. It is built in a modular and extensible way so that it can be easily extended by your needs. This session will showcase various tooling extensions which can boost your development experience by far so that you can really work offline, transpile your code in your project to use even newer versions of EcmaScript (than 2022 which is supported right now by the UI5 tooling), consume any npm package of your choice in your project, using different kind of proxies, and even stitching UI5 projects during development together to mimic your target environment.
UI5con 2024 - Bring Your Own Design SystemPeter Muessig
How do you combine the OpenUI5/SAPUI5 programming model with a design system that makes its controls available as Web Components? Since OpenUI5/SAPUI5 1.120, the framework supports the integration of any Web Components. This makes it possible, for example, to natively embed own Web Components of your design system which are created with Stencil. The integration embeds the Web Components in a way that they can be used naturally in XMLViews, like with standard UI5 controls, and can be bound with data binding. Learn how you can also make use of the Web Components base class in OpenUI5/SAPUI5 to also integrate your Web Components and get inspired by the solution to generate a custom UI5 library providing the Web Components control wrappers for the native ones.
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
Top Benefits of Using Salesforce Healthcare CRM for Patient Management.pdfVALiNTRY360
Salesforce Healthcare CRM, implemented by VALiNTRY360, revolutionizes patient management by enhancing patient engagement, streamlining administrative processes, and improving care coordination. Its advanced analytics, robust security, and seamless integration with telehealth services ensure that healthcare providers can deliver personalized, efficient, and secure patient care. By automating routine tasks and providing actionable insights, Salesforce Healthcare CRM enables healthcare providers to focus on delivering high-quality care, leading to better patient outcomes and higher satisfaction. VALiNTRY360's expertise ensures a tailored solution that meets the unique needs of any healthcare practice, from small clinics to large hospital systems.
For more info visit us https://valintry360.com/solutions/health-life-sciences
Project Management: The Role of Project Dashboards.pdfKarya Keeper
Project management is a crucial aspect of any organization, ensuring that projects are completed efficiently and effectively. One of the key tools used in project management is the project dashboard, which provides a comprehensive view of project progress and performance. In this article, we will explore the role of project dashboards in project management, highlighting their key features and benefits.
What to do when you have a perfect model for your software but you are constrained by an imperfect business model?
This talk explores the challenges of bringing modelling rigour to the business and strategy levels, and talking to your non-technical counterparts in the process.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
Preparing Non - Technical Founders for Engaging a Tech AgencyISH Technologies
Preparing non-technical founders before engaging a tech agency is crucial for the success of their projects. It starts with clearly defining their vision and goals, conducting thorough market research, and gaining a basic understanding of relevant technologies. Setting realistic expectations and preparing a detailed project brief are essential steps. Founders should select a tech agency with a proven track record and establish clear communication channels. Additionally, addressing legal and contractual considerations and planning for post-launch support are vital to ensure a smooth and successful collaboration. This preparation empowers non-technical founders to effectively communicate their needs and work seamlessly with their chosen tech agency.Visit our site to get more details about this. Contact us today www.ishtechnologies.com.au
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
8. 8
DDD Alternative
Monolithic Data Models (Big
Ball of Mud)
Anemic Data Models
Relational-Database way of
thinking
Communication Difficulties
Smaller Independent Domain
Models / Integration
Rich Behavior Objects (OOP
done right)
Persistence Ignorance
Ubiquitous Language
10. 10
What is DDD?
It is an Approach to develop software for
- Complex needs
- Evolving models
It is Not a technology or a methodology
It is a Way of Thinking
11. 11
Brief History of DDD
Eric Evans – 2003
DDD Community (http:// www.domaindrivendesign.org)
Jimmy Nilson – 2006
Greg Young – 2008 / 2013
Vaughn Vernon – 2013
P:PubTechnical_documentationDomain Driven Design (DDD)
12. 12
The Business Value of DDD
1. The organization gains a useful model of its domain.
2. A refined, precise definition and understanding of the business is developed.
3. Domain experts contribute to software design.
4. A better user experience is gained.
5. Clean boundaries are placed around pure models.
6. Enterprise architecture is better organized.
7. Agile, iterative, continuous modeling is used.
8. New tools, both strategic and tactical, are employed.
27. 27
Domain Model (Solution Space)
A system of abstractions that:
•Describes selected aspects of a domain and
•Can be used to solve problems related to that domain.
30. 30
Bounded Context
A description of a boundary (typically a subsystem, or the work of
a particular team) within which a particular model is defined and
applicable.
32. 32
Ubiquitous Language
A language structured around the domain model.
Used by all team members, within a bounded context, to connect
all the activities of the team with the software.
NOT universal!
33. 33
Ubiquitous Language - An Example
Requirements for “Customer”
•Change Personal Name
•Set Postal Address
•Relocate to Postal Address
•Change Home Telephone
•Disconnect Home Telephone
•Set Primary Email Address
•Set Secondary Email Address
47. 9/12/2013 47
Loose Coupling and High Cohesion
Decrease Coupling
Increase Cohesion
Eliminate Inappropriate Intimacy
The Law of Demeter
Tell, Don’t Ask
Say it Once and Only Once
75. 75
Wrap-Up: Strategy
•In certain cases, one Model cannot make it
•Multiple Models – Integration with Strategic Design
•Ubiquitous Language in Model, Code, Spoken & Written Language
•Be a Good Listener – Understand the Problem Space
•The “worst” Domain Expert is the Best in the World compared to us
•The obvious is not adequate. Focus on Exceptions
•How would / does the Domain function Without Computers?
•Initial Analysis and Design are Not Dogmas – Knowledge comes Slowly
Redesign
76. 76
Wrap-Up: Tactics
•Model-Driven Design as OOP done right
•Focus on What instead of How
•Focus on Behavior (hidden in Verbs) instead of Data (hidden in Nouns)
•Be familiar with, Design Patterns and Principles
•Command Query Responsibility Segregation
•Event – Driven Architecture
•Event Stores
•Hexagonal Architecture / Ports & Adapters
Refactor
77. 77
Strategic, Tactical, DDD, OOP, CQRS, UI, ES, EDA, ….
For the things we have to learn before we can do them,
we learn by doing them.
Aristotle