Hadi Ahmadi
Independent Software Architect & Consultant, Co-Founder of DDD Iran Community
Tehran, Iran
Actions
Experienced software engineer with a strong focus on modeling, design, and architecture. Works closely with diverse teams as a software architect, designer, and technical coach, helping them build design skills and align solutions with business strategies.
Links
Area of Expertise
Topics
Ubiquitous Language In Tests
(This is a hands-on lab with limited capacity)
During software development, tests are a key artifact. Apart from verifying functionality, tests are also documentation of the domain. Tests that fail to contribute to ubiquitous language may lead to misunderstandings regarding functionality and requirements. Continuously using the universal language and its terms across all sections of the project is imperative to achieving shared understanding among all project stakeholders.
This workshop focuses on using ubiquitous language in tests and refactoring existing tests to reflect the domain language. This workshop will cover the following topics:
* Paradigm shift from thinking of tests to thinking of specifications
* High-level Specifications & Low-Level Specifications
* Writing, organizing and defining specifications at a business-readable level by applying ubiquitous language.
* Language used in the technical and automation layers and executable specifications
Testing Domain Invariants with Property-Based Testing
The first step in developing a domain model, is to analyze the problem and then break it up into smaller parts. TDD is a great technique that many developers use for this purpose. Most developers use example-based approach for writing their tests and don't consider other methods.
Property-based testing requires us to approach testing differently from what we’re used to. In property-based testing, you write tests not by specifying examples, but by describing the rules and properties and generating the examples automatically.
In this hands-on, we write property-based tests for an object-oriented domain model, TDD style, and explore the way of breaking down invariants into smaller parts and develop in small increments. The purpose of the workshop is to show attendees how they can use property-based testing as a tool for exploring the problem domain and invariants more in-depth and develop in small steps.
In this sessions, we will:
- Explain Property-Based Testing
- Explain the ways of writing properties
- Describe a problem to implement
- Break down invariants into smaller parts
- Writing Properties first
- Implementing domain model to pass the tests
The examples will be available in Java and C#.
Temporal Patterns
(This is a hands-on lab with limited capacity)
Many systems need to track and keep records of changes to data. It's not just about audit logs, but the ability to travel back in time and actually use the data. For example, you can use it to analyze and predict future events, run what-if scenarios for the past, or use it in the model for solving time-oriented problems.
When dealing with these kinds of problems, event sourcing is one of the first things that comes to mind. But not all systems are using event sourcing, or are not willing to do so. Keeping track of state changes and using them when needed is what temporal patterns are all about.
The purpose of this workshop is to demonstrate how we can keep track of changes in our model by using temporal patterns. There will be different patterns discussed depending on the situation, such as whether the change is concerning a single property or an entire object.
Note: We will primarily focus on temporal patterns in object-oriented languages. Even though functional languages can be used to implement these concepts, this workshop does not cover them.
Refactoring-Enabling Refactorings
(This is a hands-on lab with limited capacity)
Most legacy systems have a strong technical resistance to refactoring. This resistance prevents many legacy systems from being touched. There can be many reasons, including developers' concern about the amount of effort required, or their fear of unexpected consequences. For a large refactoring to be successful, it is essential to overcome this resistance.
This resistance has a variety of aspects. One of them is the large number of changes that must be adapted for refactoring to be applied. Developers may need to spend a lot of time and effort because of this and Furthermore, they may be forced to rely on large rewrites instead of incremental or iterative development.
Unexpected consequences are another aspect. Most Legacy systems don't have a good test suit, if any at all. Developers are thereby exposed to unintended consequences without knowing about them in a concrete manner. Since the code is not testable, they cannot write tests to apply refactoring. It's actually a vicious cycle, since testing is essential to refactoring and placing tests requires you to refactor the code.
There are actually ways to overcome this resistance or at least mitigate its risks. Our goal in this workshop is to explore a set of techniques, guidelines, and approaches to apply the most basic and essential refactoring needed to make the code testable as well as isolate different parts to reduce the impact of future refactoring. This will reduce the resistance of the system to refactoring, both in terms of the size of changes and the fragility of the refactoring.
Refactoring with the Sandwich pattern
In this session, we'll try to solve a very common problem in software development teams: dealing with legacy procedural code without tests.
In the Sandwich pattern, we start from a class (generally an Application Service). We identify where it uses shared state (generally from a database). Then we push that code to its extremes (up and down) between which we have an immutable domain model that we can interact with.
The idea is to protect our code using Approval Tests and refactor this procedural code to domain-centric code.
We'll use good practices to finally reach services that correspond to the Sandwich pattern and coherent rich domain objects containing business behaviours.
In between exercises, we'll discuss:
- How Temporal Coupling can help us to respect our use case
- What is a pure and isolated Domain model?
- Understanding Domain Completeness
- What is the difference between an Application Service & a Domain Service ?
- Does Sandwich pattern helps us to make clean Domain Services ?
The exercises will be available in Java and C#.
Refactoring Legacy Codebases with Property-Based Testing
It is a fact that most of us have to deal with legacy projects in our careers. We spend much more time maintaining and making changes to existing code rather than writing new code. The problem is, The majority of legacy systems suffer from bad design because of forgotten refactoring or simply because the team did not come up with good design solutions in the past. Thus, we have to refactor the design to make it more maintainable and adaptable.
In refactoring, our goal is to improve the maintainability of code without changing the behavior. This can be somewhat risky since many legacy projects have almost no tests. A well-designed set of tests allows us to make changes and find out very quickly whether the changes had any side-effect.
In this talk, we will take a quick tour of what "Property-Based Testing" is, how it works, and how it can be used as a safety net for refactoring.
Language, Mind and Perception
Knowledge crunching through communication and collaboration with domain experts has been a hot topic in the DDD community, since the beginning. There have been many methods and techniques for facilitating this process, such as Event Storming and Domain Storytelling. Through these methods, we can learn more about the problem domain by gathering people together, exploring, and visualizing. Yet, We usually face significant problems, complexities, and obstacles in the Knowledge Crunching process. The fact is that every learning process contains inherent complexities. Communication difficulties, linguistic complexities, and cognitive biases are examples of these complexities.
It is widely known that learning is a bottleneck in complex domains, which is why this presentation explores some of the complexities, issues, and cognitive biases related to learning and communication.
In addition to those issues, there is another problem: Knowledge crunching is primarily viewed from the perspective of the development team. Within the DDD community, we primarily focus on improving the skills, knowledge, and awareness of developers, and we often forget about domain experts. Communication and learning are two-way processes. We believe that teaching Domain Experts to communicate effectively and making them aware of the problems and issues in this area can significantly improve the efficiency and effectiveness of the process.
With this objective in mind, this presentation is targeted not only at developers, but also all those involved in knowledge crunching processes.
Hadi Ahmadi
Independent Software Architect & Consultant, Co-Founder of DDD Iran Community
Tehran, Iran
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top