
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


Hello once again my fellow code-based creature enthusiasts!

Have you ever felt that managing pull requests can feel like navigating a complex, never-ending labyrinth where each
exit only leads to another room filled with code rather than a solution? Well, if you are nodding along or sighing
dramatically, we are about to dive deep into a pool of AI-driven pull request management tools. Buckle up, as we pit our
open-source underdog, CodiumAI's PR-Agent, against the reigning heavyweight, GitHub Copilot.

Now, just to be honest and clear: PR reviews can be as nerve-wracking (or more) as defusing an oddly colored blue-wired
bomb - under the camera of a Nokia Simens phone (for those born later, a 1MP camera). But fear not, CodiumAI to the
rescue to ensure PR reviews instead feel like a breezy walk at a picturesque park, or a quick, efficient jog if you're
in Kenya and feel so inclined. In the world of GitHub, which usually is the mecca for the developers, PR-Agent swaggers
in like a strong contender.

Itchy to know more? Scroll away!

### Opening Act - What is Github Copilot and Codium's PR-Agent?

GitHub Copilot and Codium's PR-Agent are two powerful tools designed to assist developers and streamline their coding
process.

GitHub Copilot, powered by OpenAI, essentially acts as an AI pair programmer. It leverages the knowledge of billions of
publicly available code snippets to suggest completions and generate code based on the context of your work. So, while
working on a task, it may suggest potential implementations for functions, write new code, aid in implementing best
practices, and even speed up the process of writing repetitive or boilerplate code.

On the other hand, Codium's PR-Agent is a highly capable, open-source tool designed to tackle the challenge of reviewing
pull requests efficiently. It's equipped with an impressive set of commands making pull request management a smoother
ride. With features like automated PR description generation, review feedback, question answering, code suggestions,
changelog updates, similarity check with other issues, documentation addition, and custom label generation, it gives you
much more direct control over your PR reviews.

While GitHub Copilot lends a helpful hand during the coding phase, Codium's PR-Agent steps up the game during the often
overlooked, but crucial, code reviewing process. Imagine being able to instantly describe a pull request, give immediate
feedback, improve your codes, update your changelogs, finding similar issues, generate documentation, and even creating
custom labels all with simple commands. It offers a sophisticated suite of tools that enhance your code reviewing
capabilities, making it simpler, faster, and so much more efficient. No hidden subscription fees or any
obligations. What’s not to love?

So, while GitHub Copilot serves as your sidekick while coding, Codium's PR-Agent ensures your pull requests are of the
highest quality, making it an indispensable ally in your coding workflow.

### The Ins and Outs of CodiumAI's PR-Agent

It is famously said that heavy is the crown worn by the king. In the programming world, the crown often goes to
customization as the king. CodiumAI's PR-Agent understands this better than most. It lets you tweak settings with
developer-level precision, the kind you'd want in your personal relationships, but we will stay within safe limits on
that one.

Ever wanted a software helper who's palms you can grease to sometimes look the other way during your code analysis? Just
drop in an easy `ignore.toml`. PR-Agent looks the other way, no questions asked. Just pop `ignore.toml` in and make
PR-Agent ignore certain files.

But wait, there's more.

Let's take a detailed journey about how CodiumAI's PR-Agent fits in your project, by creating a hypothetical scenario
and walking through the process.

## An Illustrated Walkthrough With CodiumAI's PR-Agent

The scenario:

Imagine we have a simple React app that uses Chakra-UI, with a couple of pages -- Login.jsx and Register.jsx. We will
work with our local repo and install CodiumAI's pr-agent as per instructions
provided [here](https://github.com/Codium-ai/pr-agent/blob/main/INSTALL.md#run-from-source).

_(Disclaimer: No actual code was harmed in writing this post)_

Here’s a quick overview of the steps to follow (assuming that you've at least gotten as far as cloning the repo):

- Navigate to the repo folder that you've just cloned:

  ```bash
  cd pr-agent
  ```

- We create a Python virtual environment before running pip install:

  ```bash
  python3 -m venv venv
  ```

- Next, set up an account on [Pinecone](https://www.pinecone.io/), a vector database required by Codium. After logging
  in, copy your API key from the 'API Keys' section or create a new key.
- Then, edit `pr_agent/settings/.settings.toml`. If it doesn't exist, create it using the following commands:
  ```bash
  cp pr_agent/settings/.secrets_template.toml pr_agent/settings/.secrets.toml
  ```

Since you might end-up running into errors when trying to run the pr-agent locally (this is because the '.secrets.toml'
file contains all possible entries, including optional ones uncommented) just use my settings.toml which has been
cleaned up:

```bash
# QUICKSTART:
# Copy this file to .secrets.toml in the same folder.
# The minimum workable settings - set openai.key to your API key.
# Set github.deployment_type to "user" and github.user_token to your GitHub personal access token.
# This will allow you to run the CLI scripts in the scripts/ folder and the github_polling server.
#
# See README for details about GitHub App deployment.

[openai]
key = "<your openai api key here>"  # Acquire through https://platform.openai.com

[pinecone]
api_key = "f8fc9404-e934-43fd-8dcc-11f51d4387a8"
environment = "gcp-starter"

[github]
# ---- Set the following only for deployment type == "user"
user_token = "<your github personal access token here>"  # A GitHub personal access token with 'repo' scope.
deployment_type = "user" #set to user by default
```

That's everything to do with installing Codium's pr-agent by building from source. Now onto the repo with our
hypothetical scenario. [Clone this repo](https://github.com/TylerMutai/codium-pr-agent-react-example.git) to efficiently
follow along.
Then run the usual within the repo's folder:

```bash
npm i
```

- We then branch out for our new feature

```bash
git checkout -b feature/hebrew-lang-support-with-rtl
```

At this point, we assume the feature is already built.
Here's [the commit listing all changes.](https://github.com/TylerMutai/codium-pr-agent-react-example/commit/d65634acce251a82d33e6dea5168009c22942ecf)

And then push our code to our branch.

```bash
git add .
git commit -m "added hebrew language support and rtl support"
git push -u origin feature/hebrew-lang-support-with-rtl
```

Next, create a PR using the provided link in the response message.

With that done, let’s say we are introducing a new feature for Hebrew language support with RTL. With PR-Agent in our
toolkit, we are ready to tackle it head-on.

First things first, we want to test our CodiumAI's PR-Agent. To do that, navigate back to the directory you cloned your
pr-agent in (which was covered earlier in this blog):

```bash
cd pr-agent
```

We then activate python's virtual environment:

```bash
source venv/bin/activate
```

We use the `reflect` command that generates some interesting queries:

```bash
python -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1  reflect
```

Voila! You get a response, automatically pushed to the PR as comments under your user. PR-Agents infers significant
changes to the code and highlights them, saving us from a deep dive directly into the 'files changed' tab (_cough_
senior developers _cough_).

Here's a snippet of the response (view it in
full [here](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issuecomment-1838951359)):

![reflect-codium-pr-agent.png](/images/posts/reflect-codium-pr-agent.png)

---

Feeling adventurous, we let AI take the wheel a bit more and asked it to show us possible improvements or changes that
can be made to our PR using the `ask` command:

```bash
python3 -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1 ask "Show me what improvements/changes can be made in this PR"
```

This is where the fun really starts. The AI generates a list of detailed improvements that we might have overlooked
otherwise. Not just grammar and optics, but actual, substantial methodology and logic improvements. I'm smiling like a
proud parent here!

Here's a snippet of the response which you can
find [here](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issuecomment-1838971826):

![questions-codium-pr-agent.png](/images/posts/questions-codium-pr-agent.png)

---

Next, we let Codium do what it does best using the `/describe` command.

```bash
python3 -m pr_agent.cli --pr_url=https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1 describe
```

This command blesses our PR with an introduction that pretty adeptly summarizes it. Applause, please!
[Here's the full description generated.](https://github.com/TylerMutai/codium-pr-agent-react-example/pull/1#issue-2024089862)

![describe-codium-pr-agent.png](/images/posts/description-codium-pr-agent.png)

---

Now comes the royal rumble, my favourite. We put CodiumAI's PR-Agent to the ultimate test – the `/review`. This not only
gives you a summary of the PR; it also analyses the level of effort required to review it, checks for security concerns,
and provides constructive feedback and code-specific suggestions. At this point I might as well review my own code!
Here's a sample:

![review-codium-pr-agent.png](/images/posts/review-codium-pr-agent.png)

---

Finally, we utilize the `/add_docs` command. This results in potential documentation being popped in directly within
your code, making it so much easier for your fellow team members. With this, you've practically got an entire PR review,
neatly wrapped and delivered to your developer doorstep with a bow on top!

![Proposed docs](/images/posts/proposed-docs-codium-pr-agent.png)
![Proposed docs two](/images/posts/proposed-docs-two-codium-pr-agent.png)

## In Conclusion...

Isn’t it amazing when machines do the tedious work for you, and you can just pop in with your insightful, intelligent
comments to seal the deal? Nothing short of what developers have always wanted. Optimize for 4 years, so that you save
an additional 3 hours every day. Well, with Codium's pr-agent, you only need 1 hour.

I mean, why slog away doing the grunt work when CodiumAI's PR-Agent can handle:

- Automating the creation of PRs with commands
- Facilitating preparation of structured and detailed descriptions
- Easy-peasy analysis of PRs
- Detailed suggestions for code improvements

And it does all of that while catering to each developer’s unique needs and control freak tendencies! It’s like having a
highly efficient, attentive, machine-based colleague who never goes on leave even on Fridays!

So, all you master tinkerers, all you fellow Dev Dudes and Dudettes, if you fancy diving head-first into the ocean of
customizable options, CodiumAI's PR-Agent is ever ready to bring out your programmer alter-ego.

Facing off against GitHub Copilot, PR-Agent shines through with its open-source label, ready to roll up its sleeves and
take your developer life to the next level. Contesting against GitHub Copilot, backed by conglomerate giant Microsoft,
PR-Agent with the strength of versatility is a reminder that the right tool is not always the biggest name but the one
that fits snugly into our unique developer lives.

Well, that's it for today folks. Until next time, keep your curly braces matched and your coffee strong!

Over and out.

Brian Baliach

---

PS: I genuinely hope this cheeky jaunt through the wonders of CodiumAI's PR-Agent and GitHub Copilot has left you with a
smirk and a better understanding of AI-driven pull request management tools. Just remember, the right choice is not
always the crowd-favourite, but the one that is custom-tailored for your unique programmer needs!

Catch more insights and all things code at my blog: https://balysnotes.com. Or don't, and miss out on some top-tier
tech wit. Your call!

Tally-ho, Brian


Navigating the Pull Request Maze with CodiumAI's PR-Agent: A Comparison to GitHub's Copilot

Showing posts from ai category

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

Navigating the Pull Request Maze with CodiumAI's PR-Agent: A Comparison to GitHub's Copilot