This document contains the key points from a presentation on Domain Driven Design (DDD). It discusses the big picture of DDD, including defining the domain and ubiquitous language. It explains why practicing DDD is beneficial and provides approaches for different project scenarios based on complexity. The presenter advocates starting with strategic modeling rather than tactical patterns, and provides examples of patterns that can be used after establishing boundaries and context with modeling.
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
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.
WordCamp Nashville: Clean Code for WordPressmtoppa
Slides from my talk at WordCamp Nashville, including notes. Covers why clean code is important, and provides 10 tips to make your code cleaner, for WordPress and beyond
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
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.
WordCamp Nashville: Clean Code for WordPressmtoppa
Slides from my talk at WordCamp Nashville, including notes. Covers why clean code is important, and provides 10 tips to make your code cleaner, for WordPress and beyond
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled."
So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself?
Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP?
This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020.
Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/
Domain driven design is help as part of software development for proper deliver of software applications.
It will help on strategic planning of software design and delivery.
Beyond Technical Debt: Unconventional techniques to uncover technical and soc...Juraj Martinka
* Traditional static code analysis tools (Sonar et al.) are notoriously bad at producing actionable insights (what does the "4000 years of accumulated technical debt" really mean?)
* CodeScene takes a different approach and focuses instead on how code evolves over time using a treasure trove we all posses - version control history.
* Come and meet CodeScene, a unique behavioral code analysis tool that looks for patterns in version control data to understand the history and evolution of a codebase: unraveling things like hotspots, change coupling between modules and interesting social aspects of the code.
* I'll describe the ideas behind CodeScene, how it works and demonstrate the techniques on analyses of real projects.
Keynote presented at GOTO Chicago (2018-04-26)
Video available at https://www.youtube.com/watch?v=AbgsfeGvg3E
Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning.
And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear in new forms and fads and technologies. Principles are revisited. Ideas once lost to the mainstream are found again.
In this keynote we revisit the present through the past, looking at the enduring principles that shape programming languages, architecture, development practice and development process, the ideas that cycle round, each time becoming perhaps a little better defined, a little more mature, and look to see what else might be on the horizon.
Gluing it all together: How teams can build enterprise JavaScript application...Codemotion
Should everyone write code in one language? Would you hire a team to build a house with only hammers? Companies, large ones, are trying to port huge systems to the browser. Is one language really the perfect tool for presentation and business logic?
This session disagrees with the single tool premise and discusses an approach to help companies integrate existing skills, web standards, and resources with different skills together, and still target the browser.
A design system is a framework of practices that bring designers and products together. It is a platform to identify, and document what to share, whether a visual style, design patterns, front-end UI components, and practices like accessibility, research, content strategy.
The role of design with enterprise organizations is expanding, spreading across product teams and influencing decision-making at higher and higher levels. This scale, paired with the array of devices, browsers, screen sizes, locales, and environments, makes it increasingly challenging to align designers and developers to deliver cohesive user experiences.
In this talk, I’ll discuss the lessons learned, the challenges faced, and best practices for creating and maintaining an effective interface design system.
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.
More Related Content
Similar to Finding balance of DDD while your application grows
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled."
So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself?
Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP?
This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020.
Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/
Domain driven design is help as part of software development for proper deliver of software applications.
It will help on strategic planning of software design and delivery.
Beyond Technical Debt: Unconventional techniques to uncover technical and soc...Juraj Martinka
* Traditional static code analysis tools (Sonar et al.) are notoriously bad at producing actionable insights (what does the "4000 years of accumulated technical debt" really mean?)
* CodeScene takes a different approach and focuses instead on how code evolves over time using a treasure trove we all posses - version control history.
* Come and meet CodeScene, a unique behavioral code analysis tool that looks for patterns in version control data to understand the history and evolution of a codebase: unraveling things like hotspots, change coupling between modules and interesting social aspects of the code.
* I'll describe the ideas behind CodeScene, how it works and demonstrate the techniques on analyses of real projects.
Keynote presented at GOTO Chicago (2018-04-26)
Video available at https://www.youtube.com/watch?v=AbgsfeGvg3E
Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning.
And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear in new forms and fads and technologies. Principles are revisited. Ideas once lost to the mainstream are found again.
In this keynote we revisit the present through the past, looking at the enduring principles that shape programming languages, architecture, development practice and development process, the ideas that cycle round, each time becoming perhaps a little better defined, a little more mature, and look to see what else might be on the horizon.
Gluing it all together: How teams can build enterprise JavaScript application...Codemotion
Should everyone write code in one language? Would you hire a team to build a house with only hammers? Companies, large ones, are trying to port huge systems to the browser. Is one language really the perfect tool for presentation and business logic?
This session disagrees with the single tool premise and discusses an approach to help companies integrate existing skills, web standards, and resources with different skills together, and still target the browser.
A design system is a framework of practices that bring designers and products together. It is a platform to identify, and document what to share, whether a visual style, design patterns, front-end UI components, and practices like accessibility, research, content strategy.
The role of design with enterprise organizations is expanding, spreading across product teams and influencing decision-making at higher and higher levels. This scale, paired with the array of devices, browsers, screen sizes, locales, and environments, makes it increasingly challenging to align designers and developers to deliver cohesive user experiences.
In this talk, I’ll discuss the lessons learned, the challenges faced, and best practices for creating and maintaining an effective interface design system.
Similar to Finding balance of DDD while your application grows (20)
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.
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
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
Listen to the keynote address and hear about the latest developments from Rachana Ananthakrishnan and Ian Foster who review the updates to the Globus Platform and Service, and the relevance of Globus to the scientific community as an automation platform to accelerate scientific discovery.
Code reviews are vital for ensuring good code quality. They serve as one of our last lines of defense against bugs and subpar code reaching production.
Yet, they often turn into annoying tasks riddled with frustration, hostility, unclear feedback and lack of standards. How can we improve this crucial process?
In this session we will cover:
- The Art of Effective Code Reviews
- Streamlining the Review Process
- Elevating Reviews with Automated Tools
By the end of this presentation, you'll have the knowledge on how to organize and improve your code review proces
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.
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/
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/
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
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.
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.
Providing Globus Services to Users of JASMIN for Environmental Data AnalysisGlobus
JASMIN is the UK’s high-performance data analysis platform for environmental science, operated by STFC on behalf of the UK Natural Environment Research Council (NERC). In addition to its role in hosting the CEDA Archive (NERC’s long-term repository for climate, atmospheric science & Earth observation data in the UK), JASMIN provides a collaborative platform to a community of around 2,000 scientists in the UK and beyond, providing nearly 400 environmental science projects with working space, compute resources and tools to facilitate their work. High-performance data transfer into and out of JASMIN has always been a key feature, with many scientists bringing model outputs from supercomputers elsewhere in the UK, to analyse against observational or other model data in the CEDA Archive. A growing number of JASMIN users are now realising the benefits of using the Globus service to provide reliable and efficient data movement and other tasks in this and other contexts. Further use cases involve long-distance (intercontinental) transfers to and from JASMIN, and collecting results from a mobile atmospheric radar system, pushing data to JASMIN via a lightweight Globus deployment. We provide details of how Globus fits into our current infrastructure, our experience of the recent migration to GCSv5.4, and of our interest in developing use of the wider ecosystem of Globus services for the benefit of our user community.
Unleash Unlimited Potential with One-Time Purchase
BoxLang is more than just a language; it's a community. By choosing a Visionary License, you're not just investing in your success, you're actively contributing to the ongoing development and support of BoxLang.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
8. Goal of this talk
■ Understand big picture of DDD
■ Be able to identify the current situation of business
■ Know the best approach given the current situation
■ Inspire and encourage the vision of bringing business
value through code
@carolkarklis
18. What is NOT
■ Business language (jargons, terms, etc)
Photo by Hans-Peter Gauster on Unsplash
19. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
Photo by Hans-Peter Gauster on Unsplash
20. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
Photo by Hans-Peter Gauster on Unsplash
21. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
■ The way developers communicate about the system
Photo by Hans-Peter Gauster on Unsplash
22. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
■ The way developers communicate about the system
■ Communication about how the system should work
(speculative)
Photo by Hans-Peter Gauster on Unsplash
23. "The practice of building up a
common, rigorous language
between developers and users"
Eric Evans
24. Ubiquitous language
It is based on domain model and express how the system works in an
understandable way for everyone in the team
A language about a shared knowledge of domain
made by the team
35. Investments takes
time
The definition of investment is to apply resource, time and
effort in exchange of something later. You must consider if the
team is willing to invest in building better software.
42. statement
The system is completely guided by data and you can classify
it as a CRUD solution (create, read, update, delete). Your
team only needs a pretty interface for data manipulation.
scenario #1
43. statement
The system is completely guided by data and you can classify
it as a CRUD solution (create, read, update, delete). Your
team only needs a pretty interface for data manipulation.
scenario #1
diagnosis
You don't need to invest time and effort from your team to
practice DDD. That doesn't mean you should not worry
about code quality.
44. statement
The system requires only 30 or less business operations, is
probably very simple to have a overview of the system. This
means that your application don't have more than 30 use
cases (methods), and each one of them have minimal business
rules. Because of that, you don't feel lack of control by
business complexity. This is a common scenario for startups
doing their MVP.
scenario #2
45. statement
The system requires only 30 or less business operations, is
probably very simple to have a overview of the system. This
means that your application don't have more than 30 use
cases (methods), and each one of them have minimal business
rules. Because of that, you don't feel lack of control by
business complexity. This is a common scenario for startups
doing their MVP.
scenario #2
diagnosis
You could even have a challenge in your mind right now, but
practicing DDD is a high cost because you didn't feel the pain
of complexity yet. Maybe is the moment to gather domain
experts and evolve the ubiquitous language.
46. What you can do
■ Evolve ubiquitous language
■ Use a tool that analyzes the code (rubocop, code
climate, source level, etc)
■ Make an organized mess
■ Analyze software metrics like Churn vs Complexity
55. Churn
It is a measure of how often a file changes. Files
that change more have bigger churn.
56. Complexity
Usually is calculated by Cyclomatic Complexity,
which calculates the quantity of independent
paths your code have (control transferences,
logical sequences, etc)
72. "What's the future cost of doing
nothing now?"
Sandi Metz, from talk "Go ahead, make a mess"
73. statement
Let's say that you moved from 30 to 40 features and your
starting to question complexity of things that need to be
done. The system may not be maintained by an unique team,
but by multidisciplinary teams. You are thoughtful about
product evolution inside each team, and questioning if is
possible to keep a stable system with code quality and
reliable architecture.
scenario #3
74. statement
Let's say that you moved from 30 to 40 features and your
starting to question complexity of things that need to be
done. The system may not be maintained by an unique team,
but by multidisciplinary teams. You are thoughtful about
product evolution inside each team, and questioning if is
possible to keep a stable system with code quality and
reliable architecture.
scenario #3
diagnosis
You are coming close to the point where there is a real
benefit in making code design: The benefit of productivity
and being happy. Your team should start talking about code
design (including DDD)
75. What you can do
■ If possible, distribute senior people across the teams, ensuring that
the team have at least one person with experience in designing code
(and failing)
■ Make periodical checks to talk about code quality and architecture
(with team leaders). Like a code therapy.
■ Make fishbowls/meetups with product managers and developers to
talk about it and analyze opportunities.
■ Start DDD with Strategic Modeling, never Tactical Patterns
76. Start practicing DDD with
Strategic Modeling
Don't start with tactical patterns. For real.
80. Defining bounded contexts
It's a component so important as ubiquitous language when practicing DDD
Is how DDD deals with models of big subdomains:
Separating they by business intentions.
84. exercise
■ Make a list of every subdomain you remember in your
routine
■ Make a list of bounded contexts
■ Use a template to understand how bounded contexts
communicate between them.
■ Do it and redo it as many times as necessary
85. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
86. statement
Muitas pessoas e features para serem administradas. Os
requisitos mudam e isso requer muito esforço do time em
pensar como manter o código atual e ainda fazer as
mudanças necessárias sem que outras coisas quebrem no
sistema.
scenario #4
87. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
diagnosis
The time has come and you should invest in code design and
practice DDD as much as possible. It's time to plan system
changes.
88. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
diagnosis
Chegou o momento esperado de investir em design de código
e praticar DDD o quanto for possível. É hora de planejar
mudanças no seu sistema.
89. What you can do
■ Collect all the effort from Strategic Modeling to use tactical
patterns
■ Make a plan and focus on execution
96. Tactical Patterns
They are also more practical than Strategic Modeling. It is worth mentioning that
these patterns are applied within a bounded context.
Resources closer to the code
97. A few patterns
■ Value Objects
■ Entities
■ Domain Services
■ Repositories
■ Aggregates
A verdade é que nós desenvolvedores somos péssimos pra identificar quando algo começa a ficar complexo
Nesse ponto tudo muda. Se o time não conseguir pegar tempo pra fazer um bom design,a performance começa a cair porque o sistema vai ficando mais engessado e difícil de modificar. Com um bom design, a performance fica mais constante e é possível ter mais entregas do que um sistema com nenhum ou péssimo design
Não precisa ser algo formal e nem muito organizado. Você pode pegar um fluxo e pedir para o especialista explicar. Por exemplo: Como funciona o fluxo de resgate?
É ISSO que você quer extrair da conversa: conceitos e palavras em comum. É assim que você testa se a linguagem do seu código reflete a realidade, e é assim que você constrói a linguagem ubíqua
Depois dessa conversa, documente ela no papel. Como esse fluxo funciona? O que é importante de ser dito sobre ele?
A ideia não é manter uma documentação 100% fiel ao código o tempo todo, mas sim extrair os conhecimentos da reunião pra algo mais duradouro
Depois de documentar o fluxo, envie para os especialistas e outros desenvolvedores. Esse é um ótimo exercício
Falar do rubocop e source level
Falar do rubocop e source level
Falar do rubocop e source level
Fazer fishbowls com o time de dev pra discutir sobre qualidade de código e espalhar conhecimento em design
Se possível, fazer com que cada time tenha pelo menos uma pessoa com experiência em design de código
Fazer checks periódicos
Aproveite a oportunidade de lançar uma feature para fazer ela do zero, e não refatorar algo que vc já tem dificuldade de usar
Não deixe a discussão sobre produto longe de refactor/design de código. Quanto mais perto, quanto mais vc mostrar a preocupação para os PM's, mais fácil
Tentar encaixar o Shapeup aqui
DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Vamos pensar nesse domínio: Ele tem intenções e contextos diferentes.
O que um usuário significa em cada um desses subdomínios?
Por exemplo, o termo CLIENTE pode ter vários significados
Quando o usuario tá na vitrine, é uma coisa
Quando faz o pedido, outra
No pedido é bem limitado, o CLIENTE representa pouca coisa: eu só quero saber o tipo de pagamento e um endereço de entrega dele
Agora vamos falar de intenções
QUal a intenção de tudo isso? Vender um produto?
Quase tudo é sobre vender um produto
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do ESTOQUE é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address
Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto.
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address
Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto.
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
is a set of technical resources used in the construction of your Domain Model, these resources must be applied to work in a single Bounded Context.