Hey everyone, back with another one series again!

This time, I reeeeeally wanted to re-inforce my learning from “Implementing Domain-Driven Design” book as a way of documenting my learning journey with the book!

So, let’s get started already! 😆

Brief about DDD Introduction

First let’s discuss what’s Domain-Driven Design, Domain Expertise and then move from there to the Development part, our part!

What’s a Domain

So, what’s a domain?

Nope, not this

A domain, is a problem, like in CAFU, FUEL delivery, that’s our Core Domain, where each of our work one way or another revolves around, affects, branches out of it

Subdomain? What’s that again?

So yea, we did mention that a domain represents a problem, but as you might have guessed, a Subdomain is like part of that domain, hence the “Sub” part prefixing the word 🤷‍♂️

Okay, but still, why is that a thing you might ask?

“because a lot of software developers think it’s clever to bake everything possible into one system.”
— Vaughn Vernon “Implementing Domain-Design”

Well… yea, exactly, seems familiar to the SRP a bit, but breaking domains down into subdomains make the problem you wanna solve more manageable, and simpler, but to do so, this requires severe understanding of the problem/domain you’re trying to solve/improve, and usually requires an expert, a Domain Expert!

Who’s the Expert? The Domain Expert!

being Domain-Driven, is all about living and breathing FUEL Delivery, knowing the customer’s pains, knowing the pilot’s pains, knowing very well what problems a customer may face, and what he thinks about when he faces them, and hence, be able to solve problems that are related to your domain

Familarizing yourself with the processes around delivering fuel, and hence become a Domain Expert

A domain expert may not specifically be us programmers/engineers, we have the product team for that, we have the founder, or probably someone we may have never met, however, having that person in your team and absorbing his knowledge about it, massively allows you to understand the domain and take better technical decisions

Why is this important?

When we start working, we need this guy. This is a person whom we depend on while developing, planning, and designing because at the cornerstone of our work, it’s very important to think about the problem and learn its edges and angles, so when we start developing (providing a solution), we make sure we solve the problem correctly

And when we try doing TDD or BDD, our domain knowledge allows us to formulate better acceptance criteria, which may translate to better test cases or better behavior with better integration tests, better challenging to the requirements, better suggestions and designs that really clicks with our users in terms of UX

Enough, We’re here for MODELS!

So, coming from this brief background, as this will serve future blog entries, let’s go back to square 1

MVC, we get the View, we get the Controller, but why or what the heck is a model, and why is it called “THAT”?

This was actually discussed in Head First: Design Patterns, MVC section

The book goes by explaining the fact that no one liked the word “model”, because it didn’t make sense

A Model for what? is it the feature? is it the View? Is it some logic, or what???

What exactly is a Model?

A Model is best described as, a "simplification", an interpretation of an abstracted real "thing", often you'd hear it at first as a "blueprint" for something that would solve a problem at hand, without caring much for details outside what it means

For example, the MVC recommended by Apple, regardless of the communication directions or patterns it suggested (be it notifications or delegates), it described logic. If you watch the first 3 videos of CS193P on YouTube, you will indeed find that the ‘M’ here is a place for logic, purely logic

Does that make it a “Logic” Model? maybe, does that make it a helper Model? Maybe

But in the terminology of design, this can go as the following names

• Domain Model

• Usecase

• Interactor

• Logic Controller

But what should we call it?

What to call a model?

According to Vaughn Vernon's "Implementing Domain-Driven Design," it's essential to differentiate between the execution of business logic and the domain model itself.

A domain model should:

1. Be focused on representing business concepts.

2. Be independent of specific application logic.

3. Capture the essence of the problem domain.

In contrast, application logic (e.g., workflows, orchestration) belongs to application services, which interact with the domain model to achieve business goals.

Key Takeaways

Understanding the distinction between domain models and application services allows us to:

• Keep our domain logic clean and focused.

• Ensure our application is flexible and easier to maintain.

• Align our code with real-world business needs.