
An active Player in the game of technology


Brian Baliach


Recently, I was asked to present on Domain Driven Design. As I delved deeper into the research, it became clear that DDD is a crucial aspect of system architecture that many developers don’t fully grasp.

Building software that aligns with complex business needs can be daunting, especially as systems grow in complexity. Domain Driven Design (DDD) offers a methodology that addresses this challenge by focusing on the business domain and its logic, thereby enabling developers to create systems that fulfill real-world business requirements.

#### What is Domain Driven Design?

**Domain Driven Design** is a software development approach that focuses on the core business domain and its logic over technological aspects. It involves creating a semantic model that mirrors real-world scenarios. This approach ensures that software components are named in a way that reflects how domain experts and stakeholders discuss the business.

Imagine a fintech company developing a loan management system. By adopting DDD, the development team creates classes like `LoanApplication`, `LoanApproval`, and `RepaymentPlan`. This makes the software model understandable to financial experts within the company, facilitating better collaboration and reducing miscommunication.

DDD therefore enhances the effectiveness of software development by aligning it more closely with business needs. By concentrating on the business’s core processes and rules, DDD ensures that the developed software is more adaptable to changing business requirements and continues to solve relevant problems.


Remember, Domain Driven Design isn't just about complex coding solutions; it's about fostering a collaborative environment where software directly solves business problems. An e-commerce platform may define a `Customer` and a `Guest User` and understanding the domain well means recognizing the difference between a `Customer` and a `Guest User`. Naming conventions like these ensure that all team members are on the same page, ultimately leading to a more cohesive and functional system.

#### Key Principles of Domain Driven Design
For this section, I'll attempt to use real world examples to better support my explanations.

1. **Ubiquitous Language**:
   Ubiquitous Language is a common language crafted by the team, including developers and domain experts. It ensures that all terms and phrases are clearly understood in the business context, eliminating ambiguities.

   **Real-World Example**: In a logistics company, terms like `Carrier`, `Shipment`, and `Delivery` are clearly defined. When developers and logistics experts use the same terminology, implementing a feature like `ShipmentTracking` becomes straightforward and error-free.

2. **Model-Driven Design**:
   This principle involves creating a conceptual model outlining all key elements of the domain, which acts as a blueprint. The model evolves over time, being continually refined to better match the domain complexities. For instance, if your domain includes entities like 'Buyer' and 'Farmer', you need to meticulously define their attributes and interactions, such as an 'Admin' entity that can 'Create User', 'Create Cash Credit Product', or 'Send Bulk SMS'.

   **Real-World Example**: In a healthcare application, entities such as `Patient`, `Doctor`, `Appointment`, and `Prescription` are modeled.A `Patient` creates an `Appointment`.  A `Doctor` treats a `Patient`. A `Patient` is given a `Prescription`.

3. **Context Boundaries (Bounded Context)**:
   Bounded Context defines clear boundaries around a particular domain model or subsystem, enabling teams to work independently without interfering with each other. For instance, in the given domain, only Admins can create cash credit products, and while Admins can create Buyers, Buyers can also register or onboard themselves.

   **Real-World Example**: In a banking application, separate bounded contexts for `Account Management` and `Loan Processing` ensure that teams working on these features do not step on each other's toes. Account management can evolve independently from loan processing.

#### Core Building Blocks of DDD

1. **Entities**:
   Entities are objects with a distinct identity that persists over time. An example is a Farmer named 'Melvin', who has a unique ID within the system.

2. **Value Objects**:
   Value Objects are defined by their attributes and are immutable. For example, a Farmer can have attributes like 'Name' and 'ID', which are value objects.

3. **Aggregates**:
   An Aggregate is a cluster of entities and value objects treated as a single unit for data changes. Each aggregate has a root entity controlling access. For example, a Farmer can be an aggregate root and may include other entities like 'Cash Credit'.

4. **Domain Events**:
   These are significant business events that trigger changes within the domain, such as placing an order or initiating bulk payments. They help decouple systems and model real-world operations.

5. **Repositories**:
   Repositories are responsible for the persistence and retrieval of aggregates, abstracting the inner workings of data access mechanisms.

#### Common Challenges in Implementing DDD

1. **Complexity in Execution**:
   Implementing DDD can seem overwhelming due to its deep modeling and upfront design focusing on domain intricacies. Starting with a critical subdomain and gradually expanding can help manage this complexity. As an example, a business building a Health Management System may start off first with patient onboarding, before moving to other sections like doctor onboarding.

2. **Integration with Non-DDD Systems**:
   Non-DDD systems might behave differently, posing challenges in maintaining data and behavior consistency. Using anti-corruption layers or dedicated interface contexts can mitigate these issues. An e-commerce platform might use API gateways to bridge legacy inventory systems with the new DDD-based application.

3. **Under- or Over-Modeling**:
   There is a risk of either over-complicating or oversimplifying the model, missing essential complexities. Regular reviews with domain experts and iterative refinement help maintain balance.

4. **Adoption and Cultural Shifts**:
   DDD requires a cultural shift towards collaboration and a strong focus on the domain. Investing in training and workshops can enhance understanding and facilitate this transition.

#### Best Practices for Domain Driven Design

1. **Collaboration Between Domain Experts and Developers**:
   Deep collaboration between business experts and developers is essential. Regular interactive sessions help refine the domain model effectively.

2. **Continuous Learning and Context Evolution**:
   The business domain evolves over time; thus, the domain model should too. Establish feedback mechanisms like retrospective meetings and model storming sessions.

3. **Keep the Model and Implementation Aligned**:
   Changes in the domain model must be reflected in the implementation. Using domain and integration events can ensure consistency.

4. **Iterative Refinement**:
   The domain model should be a living document, continuously refined based on real-world feedback and testing.

5. **Explicitly Define Context Boundaries**:
   Clear boundaries help prevent inappropriate coupling and complexity. Well-defined APIs, schemas, and contracts can manage interactions between contexts.

#### Tools and Frameworks for DDD

Technology plays a crucial role in implementing DDD effectively. Popular frameworks like NextJS, NextJS, .Net and Java Spring help build complex software systems, while modeling tools like UML diagrams and class diagrams help visualize complex domain models. For practical application, projects like Digifarm (where I'm currently employed, and the birth of this blog post) can illustrate these concepts in action.

#### Conclusion and Q&A

Effectively implementing Domain Driven Design involves more than just a technical shift; it requires a cultural transformation within development teams. This transformation fosters closer collaboration between domain experts and developers, ensuring that the software built truly serves the business objectives. By embracing DDD, organizations can create adaptable, business-aligned software capable of evolving as business needs change.

If you have any questions about DDD, feel free to ask! Whether you're curious about specific principles or need advice on tackling common challenges, I'm here to help. Stay curious!


Introduction to Domain Driven Design: Bridging the Gap Between Complex Systems and Software

If you’ve been following me, you might recall a harrowing tale of a developer coming to grips with recursion. The aptly titled 'Decoding Recursion: The Concept That Had Me Stumped'. But your cogitation and feedback suggest we dig a tad deeper. Brave ones have emerged requesting a practical walkthrough of recursion. In this sequel, we'll take a hands-on approach to recursion using the call stack/heap.

Let's hoist the mainsail and dive in.

### Under the Hood: What Happens When Functions Run?

So, matcha latte in hand, (or is it an afternoon beer?), let’s unravel what’s going on 'under the hood' when functions are involved. Every function in its operation has an allocated memory space. Avoiding the technical jargon for the sake of our shared sanity, let's visualize this as tiny compartments in your computer's brain.

When a function runs, it's like the computer opens that compartment and dumps everything the function needs inside – the variables, calculations, and that little reminder of your lunch break at 12 pm.

This "compartment" goes by a couple of names in the programming world: Stack and Heap. While they are both for storage, they differ slightly in usage. The stack is used for static memory allocation and the heap for dynamic memory allocation.

### Enter Recursion: A Practical Look

Since we're all here for recursion, let's take a prime example - factorial computation. A factorial is the product of a number (n) and all the integers below it. Remember 5! (factorial) equaling 5x4x3x2x1? Yes, that one.

In code form, a basic recursive function for a factorial would look something like (javascript this time, cause turns out, it has a much larger audience):

```javascript
function factorial(n) {
  if (n === 1) {
    return 1;
  } else {
    return n * factorial(n - 1);
  }
}
```

Now, let's visualize this on the call stack.

Every recursive call will add a layer to the stack. It's like a pile of dishes. The first call (n=5) is the first plate. Then n=4, then 3, 2, and finally 1. After that, the result bubbles up, washing the dirty dishes one by one from the top until you reach the clean plate at the bottom, i.e., the final answer.
Remember that in heaps/stacks, data is added in a first come last serve basis.
Here's a visualization:

| Heap         | Result | Code explanation                                                                        |
|--------------|--------|-----------------------------------------------------------------------------------------|
| n==1         | 1      | base case: (n==1) return 1;                                                             |
| n==2         | 1 * 2  | n is 1 (n * factorial(n-1) which comes from previous call above. result then becomes 2. |
| n==3         | 2 * 3  | n is 2, which again comes from previous call above. the result becomes 6.               |
| n==4         | 6 * 4  | n is 6, which again comes from the call above. the result becomes 24.                   |
| n==5         | 24 * 5 | n is 24, the result becomes 120.                                                        |
| final result | 120    | This is what is finally returned. 120.                                                  |


### Stack Overflow: Recursion's Gotcha!

Stack overflow – it isn't just a popular website, folks; it's recursion's Achilles heel. This happens when our recursion burrows too deep, causing the application to run out of memory space. This is because every OS assigns a running program a fixed memory allocation (i.e. 4MB worth of space). If you exhaust this space, you then might get a stack overflow /segmentation fault error. There goes the stack of dirty dishes tumbling down!

This potential drawback highlights how deep understanding of recursion can help developers optimize for performance.

### Wrapping It Up

There you have it - a code soup stirred with the call stack/heap and topped off with a sprinkle of recursion. Hopefully, this has helped demystify the concept a bit. But who knows? Perhaps our odyssey is just starting - linked lists, binary trees, sorting algorithms - all served with that recursion spice, are waiting!

Remember, fellow devs, recursion is a powerful tool and understanding how it works at every level aids in writing better, cleaner, more intuitive and more efficient code... even if it stumps us occasionally!

As always, sail through your coding voyage, one recursion at a time.



Unraveling Recursion: A Practical Look at the Call Stack and Heap

Microservices might be the heroes of scalable and reliable applications today, but let's shift gears and talk about a concept in the software development landscape that is as mind-bending as it is powerful: recursion.

As someone who enjoys the adrenaline rush of conquering coding challenges, I've come across various concepts that are the bread and butter of computer science. Some felt like meeting an old friend on the first day of school—familiar and comforting. Others were like that one high school math problem that kept me up at night. Enter recursion.

Recursion, to put it simply, is like a mythic serpent that swallows its own tail—a function that munches on itself to get to a result. My initial thought was, "Why suffer through this mind-boggling feat when a good ol’ loop could suffice?" But then, as I chewed over recursion, the mist started to fade.

### Imagine This...
Let's play with recursion's call stack visualization. Suppose a group of kids are playing with a neat stack of blocks. Each block has a unique number. The rule is: a player can only place a block on the stack if it decreases the previous number by one. The game starts with 10 and ends with 1—a stack of decrescendoing integers.

So, what does this have to do with recursion? Each block placement is akin to a function call in recursion. You place one block (function call), then another (another call), and another, till you reach the edge case — in our scenario, the number 1 block. That's when the players start to cheer and pass the stacks backwards, unwinding them while they execute some extra celebration (in our case, processing returns).

### Dividing to Conquer
Remember those divide-and-conquer strategies in ancient warfare history? They work magic in recursion too. A problem must be conquerable by breaking it down into smaller, more manageable versions of itself.  Simply take down towers one by one until the main castle surrenders.

### A Quick Dive Into Code
Let's demonstrate recursion with a problem that even I, a seasoned loop-lover, found elegant in its recursive cloak — a classic problem: calculating the factorial of a number.

The factorial of a number n (denoted as n!) is the product of all positive integers up to n. For instance, the factorial of 4 is 4! which equals 4 * 3 * 2 * 1 = 24.

A looping method would have us running circles. Here's a python example (python because, from my perspective, is closest to English):

```python
def factorial_loop(n):
    result = 1
    for i in range(2, n + 1):
        result *= i
    return result
```

But let's sprinkle the magic dust of recursion:

```python
def factorial_recursive(n):
    if n == 1:
        return 1
    else:
        return n * factorial_recursive(n - 1)
```

This second snippet embraces the soul of recursion. We define an edge case — our base condition that stops the infinite tumble down the rabbit hole (n == 1). The function then keeps calling itself, shrinking the problem down each time (n - 1), till it hits that edge case. And then the unwinding begins, with each call resolving and returning its piece of the puzzle, eventually giving us our answer.

### Why Bother With Recursion?
Sure, recursion might seem like overkill for simple problems that a loop can fix. But consider the elegance of solutions it provides for more complex issues like tree traversals, algorithmic problem solving such as the Towers of Hanoi, or graph searches. Sometimes, recursion is not just a solution; it's the most intuitive one.

### Closing Thoughts
Once I got past the intimidating facade of recursion, I found a beautiful and streamlined way of solving certain kinds of problems. Just like my transition from being a REST advocate to appreciating the swiftness of gRPC, embracing recursion has opened up new pathways in my coding journey.

If you're still feeling the heebie-jeebies about recursion, you're not alone. Take it from someone who was once stumped by the concept: the enigma of recursion is worthy of exploration. With each recursive function we write, we're training our minds to see not just the stack of problems but the stack of solutions waiting beneath. Happy recursing!


Decoding Recursion: The Concept That Had Me Stumped

Showing posts from software tag

Introduction to Domain Driven Design: Bridging the Gap Between Complex Systems and Software

Unraveling Recursion: A Practical Look at the Call Stack and Heap

Decoding Recursion: The Concept That Had Me Stumped