Why Go says “Don’t communicate by sharing memory” and how to build robust systems without external libraries.

If you come from a background in Java (like me), Python, or JavaScript, the word “concurrency” might trigger a slight sense of anxiety. We are taught that threads are dangerous, race conditions are lurking around every corner, and debugging deadlocks is a nightmare.

Then you meet Go.

Go doesn’t just offer a new way to write concurrent code; it offers a new way to think about it. But beyond the famous mantras, how does this philosophy translate to actual engineering ? And perhaps most importantly, do you need external libraries to make it work ?

The answer is a resounding NO. Everything you need to build enterprise-grade concurrent systems is built directly into the language and its standard library.

In this post, we’ll recap the core philosophies of Go concurrency, explore the patterns that make it powerful, and highlight the built-in tools that let you implement them without adding a single dependency.

1. The Core Philosophy: CSP vs. Shared Memory

The most famous quote in Go concurrency comes from Rob Pike:

“Don’t communicate by sharing memory; share memory by communicating.”

This is the principle of CSP (Communicating Sequential Processes). To understand it, we need to contrast it with the traditional model.

The Traditional Model: Shared Memory

Imagine a single-occupancy bathroom in an office or any public places.

• The Resource: The bathroom (a variable in memory).
• The Problem: Multiple people (threads) need to use it.
• The Solution: A lock on the door (mutex). You must acquire the key, use the bathroom, and return (release/unlock) the key after you use it.
• The Risk: What if someone forgets to unlock the door ? (Deadlock). What if someone sneaks in without the key ? (Race Condition).

The Go Model: CSP

Imagine a factory conveyor belt (a Channel).

• The Resource: The parts being built (data).
• The Process: Worker A places a part on the belt. The belt moves it to Worker B.
• The Safety: At any specific moment, only one person is holding the part. When it is on the belt, no one is touching it.
• The Focus: You aren’t protecting a static (shared) variable; You are managing the flow of data.

In Go: You don’t protect a variable with a lock! You pass the variable over a chan. Ownership is transferred safely from one goroutine to another.

2. The Engineering Mantra: Sequence and Backpressure

There is a second, practical mantra that follows the philosophy:

“Don’t over engineer things by using shared memory and complicated, error prone synchronization primitives; instead, use message-passing between Goroutines so variable and data can be used in the appropriate sequence.”

This is where Go shines in production. Channels aren’t just for moving data; they are for controlling time.

The Relay Race Analogy

• Shared Memory: Workers check a whiteboard every second to see if the previous step is done. (Busy waiting, complex logic)
• Channels: Workers stand in a line. Worker 2 physically cannot start until Worker 1 hands them the baton.

Why this matters:

1. Sequence Guaranteed: A receive operation ( <- ) blocks automatically until data arrives. You don’t need to write if done {...} loops.
2. Natural Backpressure: If the Consumer is slow, the Channel fills up. The Producer automatically blocks and waits. This prevents your program from consuming all RAM trying to process data faster than the database can save it.

3. The Producer-Consumer Problem (Solved Simply)

The classic Producer-Consumer pattern is kind of “Hello World” of concurrency. It solves the problem of balancing speed between data creation and data processing.

In many languages, implementing a bounded-buffer (a queue that stops accepting data when full) requires complex condition variables and locks.

The Traditional Way (as conceptually handled in Java)

// Requires Mutex, Condition Variables, Wait(), Signal(), etc.
// Easy to get wrong. Hard to read.
void put(item) {
    lock.acquire();
    while (queue.isFull()) { condition.wait(); }
    queue.add(item);
    condition.signal();
    lock.release();
}

The “Go” Way

In Go, a Buffered Channel is a thread-safe Producer-Consumer queue.

// Create a buffer that holds exactly 5 items
buffer := make(chan int, 5)

// Producer
go func() {
    for i := 0; i < 100; i++ {
        buffer <- i // Automatically blocks if channel is full (Backpressure!)
    }
    close(buffer)
}()

// Consumer
go func() {
    for item := range buffer { // Automatically blocks if channel is empty
        process(item)
    }
}()

That’s it. No locks. No condition variables. No manual signaling. The language runtime handles the synchronization for you.

4. The Go Standard Toolbox (No External Libraries Needed)

One of Go’s greatest strengths is that you do not need third-party frameworks to handle different patterns of concurrency. The standard library is batteries-included.

+---------------------+----------------+------------------+--------------+
|.  Pattern.          |. Tool.         | Package.         |.  Built-In ? | 
+---------------------|----------------|------------------|--------------+
| Lightweight Threads | goroutine      | Language Keyword |  ✅ Yes      |
| Communication       | chan           | Language Keyword |  ✅ Yes      |
| State Protection    | sync.Mutex     | sync             |  ✅ Yes      |
| Wait Groups         | sync.WaitGroup | sync             |  ✅ Yes      |
| High Perf Counters  | atomic         | sync/atomic      |  ✅ Yes      |
| Lifecycle/Timeout   | context        | context          |  ✅ Yes      |

Structure Concurrency with context

In traditional concurrency, knowing when to stop a goroutine is hard. Go solves this with the context package. It allows you to cascade cancellation signals.

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Pass ctx to your goroutines. 
// If the timeout hits, all listening goroutines stop gracefully.

This prevents goroutine leaks, a common bug in other languages where background tasks keep running forever after a request finishes.

5. When to Break the Rules

While “Share memory by communicating” is the default path, Go is pragmatic. As an engineer we know that there’s “size fits for all”. It always depends on the usecase / problem we’re trying to solve. There are times when shared memory is better:

1. Simple State: If you just need to protect a simple config map or cache, a sync.Mutex is often clearer than setting up a channel loop.
2. Performance: Channels have a small overhead. For extremely high-frequency counters, sync/atomic is faster.
3. Internal State: If a struct has internal state that shouldn’t be exposed, protecting it with a mutex inside its methods is cleaner.

The Rule of Thumb:
- Use channels to orchestrate flow (pipelines, worker pools)
- Use mutexes to protect state (caches, configs)

6. Beyond the Basics: Actor Model & Async

Go’s model is unique compared to other ecosystems:

• Vs. Async/Await (JS/Python): Go hides the complexity. You write code that looks synchronous (e.g., response:= http.Get(...)), but the runtime parks the goroutine efficiently. No callback hell, no explicit await keywords everywhere.
• Vs. Actor Model (Erlang/Elixir/Akka): Go is similar but more flexible. In Actor Model pattern: mailboxes (channel in Go) belong to actors. In Go, channels are independent entities that multiple goroutines can share. However, you can build an Actor in Go using a goroutine + switch statement + channel, but you aren’t forced into that paradigm.

Conclusion

Concurrency in Go is not just about doing multiple things at once; its about composing those things safely.

By adopting the CSP philosophy, you shift your mindset from protecting resources (locks) to managing flow (channels). By leveraging the built-in tools like chan, context, and sync, you avoid the dependency hell common in other ecosystems.
You get:
1. Safety: Race conditions are harder to introduce.
2. Backpressure: Systems self-regulate under load.
3. Simplicity: Complex workflows look like simple pipeline.
So.. the next time you face a concurrency problem, remember the mantra: Don’t communicate by sharing memory. Share memory by communicating. And trust the tools that come right out of the box.

Finally after 5 years I got the chance to write again. This is the second part of my whole five-planned series as shown below:

1. Python 3 Introduction.
2. Python 3 More Advanced Concepts → you are here
3. Develop your First Micro-service (coming soon)
4. Python for Data Enthusiast (coming soon)
5. Utilizing Generative AI (LLM) for building an AI-based Application (coming soon)

Python 3 More Advanced Concepts

This part will comprise of these following sections:

1. Object Oriented Programming (OOP) in Python
2. Decorator in Python
3. Python List Comprehension
4. Generators in Python
5. Context Manager
6. Asynchronous Programming
7. Lambda Function

Caveats:
This is going to be a very long article due to lots of topic that we’re going to cover within one post, hence I would suggest to read each section separately whenever you’re free or feels like to do it.

Hope you’ll like it and let’s jump in !

Object Oriented Programming (OOP) in Python

I won’t go into the details about what OOP is since we can find it a lot from anywhere today . I would recommend to start by asking ourselves on why we need OOP at the first point, and subsequently start with the 4 basic principles of OOP such as : Encapsulation, Inheritance, Polymorphism, and Abstraction. One of the good one can be read from educative.io/blog/object-oriented-programming.

> Defining a Class in Python

Once you got all the points and good reasons for OOP, let’s see how to implement it in Python3 by defining a standard class to represent the “CustomerAccount” in a Bank called “Bank-RUPT” below:

class CustomerAccount:

  # disclaimer (this doesn't represent a real bank name)
  bank_name = "Bank-RUPT"

  def __init__(self, acc_no: str, acc_type: str, balance: float):
    self.acc_no = acc_no
    self.acc_type = acc_type
    self.balance = balance

  def withdraw(self, amt: float):
    if self.balance < amt:
      raise Exception("Balance is not sufficient!")

    self.balance -= amt
    print(f"{amt} is withdrawn from your account.")
    print(f"Your balance now is {self.balance}")

  def deposit(self, amt: float):
    if amt <= 0:
      raise Exception("Deposit amount should be greater than 0.00!")

    self.balance += amt
    print(f"{amt} has been added into your account.")
    print(f"Your balance now is {self.balance}")

  def current_balance(self):
    return self.balance

  def compare_customer_balance(cust1, cust2):
    if cust1.current_balance() > cust2.current_balance():
      return cust1
    return cust2

Some notably points here:

1. We use keyword class to define a class named CustomerAccount, ended with colon ( : )
2. There are two types of fields / attributes can be defined within a Python class respectively as follow:
   - Class Field, i.e. field that is attached into the class itself, hence any instance of the class will have the same value for it. In our sample for theCustomerAccount class, bank_name falls into this type. So, whenever you update the value of the bank_name, all instances / objects of the CustomerAccount class will always refer to the same value. This is the same concept as what we used to know in Java for static fields.
   - Instance Field, i.e. field that is attached into the instance / object of the class. As you might guess, all fields / attributes belong to this type will have their own value (specific to each instance). So, you can guarantee that you can have different value for each instance of the class. In our sample for the CustomerAccount class … acc_no, acc_type, and balance are instance fields.
3. To avoid any ambiguities, any function defined within a class will be known as method.
4. You define the constructor of the class with a special (built-in) method named __init__.
5. All Instance fields should be defined within constructor (i.e., __init__ method).
6. Method in a class can either be an instance-method (a.k.a. static-method) or class-method. What make them different is that an instance-method cannot be called directly from the class (i.e., we must call any instance-methods from an instance created from that class), while a class-method can be called directly from the class (i.e., without creating any instance). Same as what I explained on the instance field vs class field.
7. Any instance-methods within a class must have one special parameter namely self, and it must be defined as the first parameter before other parameters are defined. In our sample for the CustomerAccount class, withdraw, deposit, and current_balance are the instance-methods.
8. Any class-methods can be defined with “NO” self parameter at all. In our sample for the CustomerAccount class, compare_customer_balance is a class-method.

And below is the code snippet on how to use the CustomerAccount class along with some comments to describe on what each statement is doing:

# use class attribute / field
# notice that you can directly access the class attribute 
# without creating any instance
print(f"Welcome to {CustomerAccount.bank_name}!\n")

# creating two CustomerAccount instances / objects by calling the class's constructor
# (i.e. the  __init__ method)
first_customer = CustomerAccount("911007212", "DEPOSIT_ACCOUNT", 0)
second_customer = CustomerAccount("911007213", "DEPOSIT_ACCOUNT", 100000)

# try to withdraw an amount of $70,000 from first customer's account
try:
  first_customer.withdraw(70000)
except Exception as e:
  print(f"{e}")

# check first customer's balance
print(first_customer.current_balance())

# deposit $90,000 to customer's first account
first_customer.deposit(90000)

# print out first and second customer's current balance
print(f"First customer current balance is: {first_customer.current_balance()}")
print(f"Second customer current balance is: {second_customer.current_balance()}")

# compare two customer's balance of account and returns the greater one.
# (calling CustomerAccount's class method directly without creating an instance)
print(CustomerAccount.compare_customer_balance(first_customer, second_customer))

> Python Built-in Methods

Next, let’s also discuss on some built-in methods those will be automatically inherited by any class we created in Python. Each of these what being also known as “dunder” (double-underscore) methods has their internal default implementation that we can override by writing our custom logic inside, and that’s what make them so special 😼.

Note that I’m not going to discuss all of those built-in methods here since there are so many of them. Yet, I merely discuss on those that I personally used frequently as follow:

__str__(self)
→ By default, this special method will be called by the Python interpreter when you print the class object (instance) through a print statement as what we saw earlier in our code snippet as follow:

print(Customer.compare_customer_balance(first_customer, second_customer)) 

If you run the above statement, you’ll get more or less something as shown below:

<__main__.CustomerAccount object at 0x104276690>

As we can see that by default the python interpreter will implicitly invoke the built-in __str__(self) method, and the default implementation for this built-in method was to return the string representation of the Class’s object memory location. We can override this default behavior by writing our custom logic as follow (I deliberately hide some of the lines of code for brevity):

class CustomerAccount:

  # __init__ method goes here

  # other methods are written here

  def __str__(self):
    return f"\nAccount Number: {self.acc_no}\nType of Account: {self.acc_type}\nCurrent Balance: {self.balance}"

__lt__(self, other)
→ This built-in method can be used to define the behavior for the less-than operator ( < ). For example if we’re looking to compare the two instances of the previous Customer objects defined in our as below:

print(first_customer < second_customer)

The Python interpreter will implicitly call the built-in __lt__(self, other) method, and it’s going to raise a runtime exception like:

    print(first_customer < second_customer)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'CustomerAccount' and 'CustomerAccount'

Since there’s no way for the interpreter to know how to compare these two objects. To overcome this, we can write our custom implementation logic as below:

class CustomerAccount:

  # __init__ method goes here

  # other methods are written here

  def __str__(self) -> str:
    return f"\nAccount Number: {self.acc_no}\nType of Account: {self.acc_type}\nCurrent Balance: {self.balance}"

  def __lt__(self, other) -> bool:
    return True if self.balance < other.balance else False

__eq__(self, other)
→ This built-in method is used to compare whether two instances of the same class are equal or not, i.e. equality operator ( == ). The default behavior will be to do the comparison based on the memory address. For example given this following code:

# creating two CustomerAccount instances / objects by calling the class's constructor
# (i.e. the  __init__ method)
first_customer = CustomerAccount("911007212", "DEPOSIT_ACCOUNT", 0)
second_customer = CustomerAccount("911007213", "DEPOSIT_ACCOUNT", 100000) 
third_customer = CustomerAccount("911007212", "DEPOSIT_ACCOUNT", 50000)

print(first_customer == third_customer)

Running the above code will give us false being printed on the terminal because the first_customer and third_customer are different instances / objects stored inside the memory. Hence, false will be returned when these two objects being compared to each other.
Now, let’s override this default behavior by overriding the built-in __eq__(self, other) method in our CustomerAccount class.

class CustomerAccount:

  # __init__ method goes here

  # other methods are written here

  # other "dunder" methods are written here

  def __eq__(self, other) -> bool:
    return True if self.acc_no == other.acc_no \
      and self.acc_type == other.acc_type else False

Now, we’ll get true printed within our terminal if we’re running the same code as before since we evaluate the customer account based on their account number ( acc_no ) and account type ( acc_type ) irrespective that other fields having different values.

__call__(self, *args, **kwargs)
→ This will enable our instance class to be called as a function.

So…, given our code snippet below:

# creating two CustomerAccount instances / objects by calling the class's constructor
# (i.e. the  __init__ method)
first_customer = CustomerAccount("911007212", "DEPOSIT_ACCOUNT", 0)
second_customer = CustomerAccount("911007213", "DEPOSIT_ACCOUNT", 100000) 

first_customer()
second_customer()

If we’re trying to run the code now, it will raise a TypeError exception with a message: CustomerAccount object is not callable.
In order to address this issue, we can define our custom __call__(self, *args, **kwargs) method within our CustomerAccount class as follow:

class CustomerAccount:

  # __init__ method goes here

  # other methods are written here

  # other "dunder" methods are written here

  def __call__(self, *args, **kwargs):
    print(self)

> Class “Inheritance” and “Polymorphism” in Python

Now, let’s discuss about how to apply inheritance in Python class.
Given that we need to store all personal information for our customer such as first-name, last-name, gender, etc.. we’re going to create another class to represent these attributes in another class named Customer.

from datetime import date

class Customer:
  
  def __init__(self, fname: str, lname: str, gender: bool, dob: date):
    self.fname = fname
    self.lname = lname
    self.gender = gender
    self.dob = dob

  def register(self):
    print(f"Registered {self.lname}, {self.fname} into the system.")

  def __str__(self):
    return f"\nCustomer Fullname: {self.fname} {self.lname}\n\
Gender: {'Male' if self.gender is True else 'Female'}\nDate of Birth: {self.dob}"

And we’d like to bind our previous CustomerAccount class to this newly created Customer class. There are several ways for doing this, but in this particular context I would opt to change (refactor) our CustomerAccount class to be a child of the Customer class, so the CustomerAccount will implicitly has all attributes / members of it’s parent class (i.e., Customer class). Following is our CustomerAccount class after being refactored:

from datetime import date

class CustomerAccount(Customer):

  def __init__(self, fname: str, lname: str, gender: bool, dob: date, \
      acc_no: str, acc_type: str, balance: float):
    super().__init__(fname, lname, gender, dob)
    self.acc_no = acc_no
    self.acc_type = acc_type
    self.balance = balance

  def __str__(self):
    return f"{super().__str__()}Account Number: {self.acc_no}\n\
Type of Account: {self.acc_type}\nCurrent Balance: {self.balance}"

  # rest of the methods here

As we can see, we just need to put the parent class name (i.e. Customer) surrounded with parentheses after the child’s class name (i.e. CustomerAccount). Another important thing to mention here is that we also need to adjust the __init__ method of child class by providing all inherited fields from the parent class ( fname, lname, gender, and dob ) and call the parent’s class __init__ method through super().__init__ in order to set each value of the all inherited fields that it got from the parent class.
There’s another way for doing this in a much cleaner way later once we get into the decorator topic 😼.

Other than using any existing functionalities provided by the super (parent) class, with respect to the class behaviors… there are some benefits that we can get through inheritance as follow:

1. Extend (enrich) the existing class functionalities. As an example, we can add a new functionality to calculate tax into the CustomerAccount class.
2. Override the existing class functionalities that was inherited from the parent class.

Check these 2 following code snippets:

class CustomerAccount(Customer):
  
  # disclaimer (this doesn't represent a real bank name)  
  bank_name = "Bank-RUPT"

  # __init__ method goes here

  # this method will override it's parent `register` method
  def register(self):
    print(f"Opened a new bank account for {self.lname}, {self.fname}.\n")

  # other methods are written here

from typing import List

customers: List[Customer] = list()

customers.append(Customer("Go Kou", "Son", True, None))
customers.append(CustomerAccount(\
  "Yauri", "Attamimi", True, None, "911212707", "DEPOSIT", 100000))

for customer in customers:
  customer.register()

When you run the code, you’ll get two different outputs from each customer’s register method depends on each runtime object’s type it holds. This is one of the feature provided by what so called as “Polymorphism”.

> Class “Encapsulation”” in Python

As a quick refreshment, “Encapsulation” essentially is a mechanism that is used for hiding the information. In the OOP context, it means to hide object’s internal representation or state implementation details from the outside.
In essence, we can achieve this in most languages (e.g., Java, Typescript, ECMAScript, etc) through what so-called access modifier / control specifier, i.e. public, protected, and private. However, what make python a bit different from those languages is that Python doesn’t explicitly use those keywords, instead it uses semantics as follow:

• By default, all attributes / fields and methods defined within a class will be treated as public. Hence they can be accessed directly from the outside.
• To make either an attribute or method as protected, use single under-score ( _ ) as the prefix.
• To make either an attribute or method as private, use double under-score ( __ ) as the prefix

Let’s modify both our Customer and CustomerAccount classes as follow:

1. Change the Customer date of birth ( dob ) instance field and the CustomerAccount instance field for balance to private attributes so they can’t be accessed directly from the outside, and
2. Provide a setter (mutator) and getter (accessor) methods so that any client’s code that need to access these attributes can access it from these respective methods.

class Customer:

  def __init__(self, fname: str, lname: str, gender: bool):
    self.fname = fname
    self.lname = lname
    self.gender = gender
    self.__dob = None

  def set_dob(self, dob):
    self.__dob = dob

  def get_dob(self):
    return self.__dob

  def register(self):
    print(f"Registered {self.lname}, {self.fname} into the system.")

  def __str__(self):
    return f"\nCustomer Fullname: {self.lname}, {self.fname}\n\
      Gender: {'Male' if self.gender is True else 'Female'}\n\
      Date of Birth: {self.__dob}\n"


class CustomerAccount(Customer):

  # disclaimer (this doesn't represent a real bank name)
  bank_name = "Bank-RUPT"

  def __init__(self, fname: str, lname: str, gender: bool, \
      acc_no: str, acc_type: str):
    super().__init__(fname, lname, gender)
    self.acc_no = acc_no
    self.acc_type = acc_type
    self.__balance = 0

  # this method will override it's parent `register` method
  def register(self):
    print(f"Opened a new bank account for {self.lname}, {self.fname}.")

  def current_balance(self):
    return self.__balance

  def withdraw(self, amt: float):
    if self.__balance < amt:
      raise Exception("Balance is not sufficient!")

    self.__balance -= amt
    print(f"{amt} is withdrawn from your account.")
    print(f"Your balance now is {self.__balance}")

  def deposit(self, amt: float):
    if amt <= 0:
      raise Exception("Deposit amount should be greater than 0.00!")

    self.__balance += amt
    print(f"{amt} has been added into your account.")
    print("Your balance now is {self.__balance}")

  # Other methods written here

And following is the code snippet to test those two modified classes:

customer = CustomerAccount("Bruce", "Lee", True, "911212009", "DEPOSIT")
print(customer)

customer.set_dob(date(1973, 7, 20))
customer.deposit(1000000)

print(customer)

That’s the end of the OOP topic for Python, and you can grab the latest code for this OOP section from my GitHub.

Decorator in Python

“Decorator” is one of the design pattern as promoted by the famous Gang-of-Four (GoF) Design Patterns book. It falls under the category of “Structural Design Pattern”. See its definition from Wikipedia below:

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other instances of the same class. — Wikipedia

In essence, decorator is useful to enrich the behavior / functionality of an object (instance) without impacting other objects / instances of the same class.

There are two types of decorator in Python, i.e. “Function Decorator” and “Class Decorator”.

> “Function Decorator” in Python

Let’s say i have a function that returns sum of 1 to 1_000_000 below:

def sum():
  sum = 0
  for i in range(1000000):
    sum += i
  return sum

if __name__ == "__main__":
  print(sum)

Running the program and we’ll get output something similar to this:

Now, let’s say if i want to measure the performance of the function by subtracting the finished time against its starting time. However, I don’t want to modify my original sum function, instead I’m looking to wrap my existing sum function with another function that I build as a decorator. See the following code:

import time

def processing_time():
  
  def wrapper(fn):
    start = time.process_time()
    print('Starting at', start)
    print(fn())
    end = time.process_time()
    print('finished at', end)
    print('process took', "{:.8f}".format(float(end - start)), "s")

  return wrapper

def sum():
  sum = 0
  for i in range(1000000)
    sum += i

  return sum

if __name__ == "__main__":
  sum = processing_time(sum)
  sum()

Running the program will give you something similar as follow:

Some key-takeaways here:

• We create another function called processing_time(), and basically this is our decorator function.
• Within our decorator function, we define another inner function called wrapper that will take any function as it’s parameter as denoted by fn, and this is feasible because Python treat function as a first-class-object (a.k.a. first-class-citizen) which make it can be passed anywhere within our code (e.g., as a function argument, as a returned value, etc).
• Inside the wrapper(fn) function, we can basically write any additional logics as we’d like to before and/or after calling our decorated function which is sum in this context. In our case, we capture the start-time before calling the sum function, and finalize with capturing the end-time and also performing a basic subtraction (i.e., end-start). Then we return the wrapper function to be automatically invoked later by the Python interpreter.
• Last but not least, there are few ways for us to test our decorator. The first one as shown in our sample above is by passing our sum function as an argument into ourprocessing_time decorator function. Another way that we can do is through an annotation tag (similar like Annotation in Java, i.e., @ ). Check the code below and compare it with the previous one without @:

# our decorator function is written here

@processing_time # --> apply decorator through '@' tag
def sum():
  sum = 0
  for i in range(1000000)
    sum += i

  return sum

if __name__ == "__main__":
  sum() # --> here we just call our decorated function without wrapping it anymore

Now let’s see how we can utilize ourprocessing_timedecorator function to our previous sample on the CustomerAccount class, in particular to both method deposit and withdraw. Check the code below:

import time

def processing_time(fn):

  def wrapper(*args, **kwargs):
    start = time.process_time()
    print("starting at", start)
    print(fn(*args, **kwargs))
    end = time.process_time()
    print("finished at", end)
    print("process took", "{:.8f}".format(float(end - start)), "s")

  return wrapper


class CustomerAccount(Customer):

  # disclaimer (this doesn't represent a real bank name)
  bank_name = "Bank-RUPT"

  # init method goes here

  # other methods were hidden for brevity

  @processing_time
  def withdraw(self, amt:float):
    if self.__balance < amt:
      raise Exception("Balance is not sufficient!")

    self.__balance -= amt
    print(f"{amt} is withdrawn from your account.")
    print(f"Your balance now is {self.__balance}")

  @processing_time
  def deposit(self, amt: float):
    if amt <= 0:
      raise Exception("Deposit amount should be greater than 0.00!")

    self.__balance += amt
    print(f"{amt} has been added into your account.")
    print(f"Your balance now is {self.__balance}")

Did you notice some changes in our processing_time decorator function ?

As you know that both our CustomerAccount.withdraw and CustomerAccount.deposit methods have parameter|s (i.e. amt). Hence, we can’t apply the same processing_time decorator function as before. It will definitely raise a runtime error (i.e. TypeError ) if we force to use the same processing_time as before.

Therefore we need to “tweak” a little bit our processing_time decorator function as shown above. If you are curious about args and kwargs usages in python, you can refer to this link.

> “Class Decorator” in Python

In essence, once we understand the concept of “Function Decorator”, this part should be quite straightforward for us. What make this “Class Decorator” a bit different is that when we decorate a function with a class, the function is automatically passed as the first argument to the class init constructor, hence we set this function as one of the attribute of our class decorator’s object. In other words, when we decorate a function / method with a “Class Decorator”, that particular function / method becomes an instance of the “Class Decorator”. With this being said, you have to be careful in the case of any attributes being accessed by your instance method won’t be available anymore within the “Class Decorator”.
Yet, it won’t be a problem in case you apply the “Class Decorator” to a function or static method.

To see how this works, let’s add another function (static method) into our CustomerAccount class that takes CustomerAccount object as it’s argument and calculate and returns the customer’s credit score as shown below:

class CustomerAccount(Customer):

  # other lines were hidden for brevity

  def calculate_credit_score(cust) -> float:
    if cust.current_balance() > 0 and cust.current_balance() < 1000:
      return 0.01
    if cust.current_balance() > 1000 and cust.current_balance() <= 10000:
      return 0.05
    if cust.current_balance() > 10000 and cust.current_balance() <= 50000:
      return 0.10
    if cust.current_balance() > 50000 and cust.current_balance() <= 100000:
      return 0.25
    if cust.current_balance() > 100000:
      return 0.50

    return 0.00

Next, let’s create a new “Class Decorator” that writes into a log file named log.txt.

from datetime import datetime
import time


class Logger:
  
  def __init__(self, fn):
    self._fn = fn

  def __call__(self, *args, **kwargs):
    start = time.process_time()
    file = open("log.txt", "a+")
    result = self._fn(*args, **kwargs)
    output = f"{datetime.now()} - {self._fn.__name__} is executed. Time taken: {float(time.process_time() - start)} s\n"
    file.write(output)
    file.close()
    return result

and apply this decorator into our calculate_credit_score static method.

class CustomerAccount(Customer):

  # other codes here

  @Logger # --> our class decorator
  def calculate_credit_score(cust) -> float:
    # logics here

Running the program should produce one file named log.txt in your project root folder contains something similar as follow:

That’s all for “Decorator in Python”.
As usual, the latest code for this can be grab from my GitHub.

Python List Comprehension

Basically “List Comprehension” is just a syntactic sugar for creating an iterable object (e.g. list, tuple, dictionary, and string) in Python. In most cases, it helps us to make our code more concise and clear.
The basic structure for “List Comprehension” is as follows:

[expression for item in iterable if condition]

• expression:
  the value or transformation to apply to each item in the iterable object.
• for item in iterable:
  the loop that iterates over each element in the iterable.
• if condition:
  (Optional) a filter that selects elements to be included in the new list.

For instance, to create a list of squares from number 0 to 9, some folks might be writing something as follows:

squares = []
for i in range(10):
  squares.append(i**2)

print(squares) # output: [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

with “List Comprehension”, we can write something more concise and clear as below:

squares = [i**2 for i in range(10)] 
print(squares) # output: [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

we can also add a filter based on if condition.

squares = [i**2 for i in range(10) if i % 2 == 0]
print(squares) # output: [0, 4, 16, 36, 64]

How about working with string ? sure we can 👇

uppercase = [char.upper() for char in 'python']
print(uppercase) # output: ['P', 'Y', 'T', 'H', 'O', 'N']

There’s no limitation on the number of `for item in iterable` we use. Check the code below that utilize “List Comprehension” for flattening the two-dimensional list (Matrix).

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
flattened = [num for row in matrix for num in row]
print(flattened) # output: [1, 2, 3, 4, 5, 6, 7, 8, 9]

Compare with how we use traditional loop to achieve the same thing below:

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
flattened = []
for row in matrix:
  for num in row:
    flattened.append(num)

print(flattened) # output: [1, 2, 3, 4, 5, 6, 7, 8, 9]

Over to you now, which one you’ll choose ? 😼

> Rules of Thumb

There are several rules of thumb we might consider when deciding between “List Comprehension” or traditional way (e.g. loop) for creating list.

1. Readability
   List Comprehension:
   - Use this merely simple transformations and/or filters.
   - Make sure that your list comprehension is easy to understand.
   - Avoid using list comprehension if they become too complex and hard to read.
   Traditional Loops:
   - Use this if the logic is complex or requires multiple steps.
   - Traditional loop can be more readable for complicated operations, as they allow for better structuring and commenting and easier to debug.
2. Performance
   List Comprehension:
   - Generally faster due to its internal optimizations, yet please make sure that your logic is not too complex to be digested by other fellow engineers.
   Traditional Loops:
   - Can be more flexible and easier to optimize for specific cases where list comprehensions may fall short.
   - Useful when additional operations or function calls are needed within the loop.
3. Side Effects
   List Comprehensions:
   - Avoid using this if the operation has side effects (e.g., modifying external variables, I/O operations)
   Traditional Loops:
   - Use this if the operation has side effects to make the code clearer and easy-to-maintain.

Generators

In essence, “generators” in Python is considered as a fancy-way to create iterators, which are object that holds a sequence of values and provide sequential traversal through a collection of items such as lists, tuples, sets, and dictionaries.

“Generators” make it easy to work with data one piece at a time (a.k.a. lazy-loading), especially if we don’t want to load everything into memory at once (a.k.a. eager-loading). So, “generators” give us flexibility to iterate over data without creating a complete list in memory, instead..they produce values one at a time as we need them. Thereby, “generators” don’t calculate values until we actually need them (lazy evaluation) which save memory a lot for us.

> Writing “Generator” Function

Let’s create a generator function that produces numbers from 1 to 10, one at a time.

def number_generator():
  for i in range(1, 11):
    yield i

Or, we can also use yield from with list comprehensionas follow:

def number_generator():
  yield from [i for i in range(1, 11)]

Notice the yield i line — this is what makes number_generator function a generator. When we call yield, Python pauses the function and saves the current state, and i is returned to the caller. Thus, yield keyword is the core of a generator. When a function has yield instead of return, it becomes a generator function.

Please also note that yield can merely be defined within a function. You’ll get something such as SyntaxError : yield outside function exception if you’re trying to define / call yield without / outside a function.

> Using the “Generator” Function

Using loop to access generator:

# Create a generator
gen = number_generator()

# Use loop to access values produced by the generator
for number in gen:
  print(number)

1. When the for loop starts, gen begins at the first value (1).
2. It calls yield and outputs 1, then pauses.
3. Each time the loop continues, the generator resumes from where it left off, producing 2, 3, and so on until 10.
4. After yielding 10, the generator ends.

Using next to access generator:

gen = number_generator()
print(next(gen)) # Output: 1
print(next(gen)) # Output: 2
print(next(gen)) # Output: 3

# and keep calling `next` until we get a StopIteration exception

> Benefits of Generators

• Memory Efficiency: They don’t store all values in memory since they generate each value as we need it.
• Lazy Loading / Lazy Evaluation: Ideal for large datasets (potentially infinite datasets), as they compute values only as required.
• Simplifies Code: They’re great way to handle sequences that are calculated on-the-fly without needing complex data structures.

Context Manager

It’s common that writing or building an application will be often dealing with managing I/O resources such as database, file, etc. The usage of these resources are most likely cannot be avoided since we need to maintain / persist the data either in files or databases. However, these resources are limited in supply. Therefore, we need to be careful in making sure to release these resources after usage. If they are not released, it will lead to resource leakage and may cause the system either slow down or crash (unavailable). Traditionally, we need to write some cleanup code by ourselves in order to free/release all resources after their usages which is pretty tedious and don’t be surprised that we might also forget to write this cleanup code that can lead to resource leakage as mentioned earlier.

In Python, there’s a mechanism that can help us to automate setup and teardown resources with the usage of the context managers that facilitate the proper handling of resources.

> File Handling without Context Manager

Check the following example on how we handle manually the cleanup code (i.e., closing the file) after its usage:

file = open("my_file.txt", "r", encoding="utf-8")
for line in file:
  print(line)

file.close() #you close the file after the usage which sometimes this can be forgotten

> File Handling with Context Manager

Check the following example on how we use context managers to automatically handling file resources with the help of with statement. With this approach, the file will be automatically released after its usage, and we don’t need to explicitly write any logic for it.

with open("my_file.txt", "r", encoding="utf-8") as f:
  print(f.read())

> Creating a Custom Context Manager

We can also create our own context manager. When creating Context Manager using class, we need to ensure that the class has special methods (dunder methods) namely __enter__() and __exit__().

The __enter__() returns the resource that needs to be managed while the __exit__() does not return anything but used to performs the cleanup operations (i.e., release any resources after the usages). Check the example below:

class ContextManager():
  def __init__(self):
    print('init method called')
  
  def __enter__(self):
    print('enter method called')
    return self

  def __exit__(self, exc_type, exc_value, exc_traceback):
    print('exit method called')


with ContextManager() as manager:
  print('with statement block')

The above code will be creating an object of type ContextManager that is assigned to variable named manager. And, when the program is running, these following will be get executed in sequence:
- __init__()
- __enter__()
- statement body, i.e. code inside the with block
- __exit__()

Using the same approach, we can create our custom ContextManager to handle file operation as follow:

class FileManager:
  def __init__(self, filename, mode):
    self.filename = filename
    self.mode = mode
    self.file = None

  def __enter__(self):
    self.file = open(self.filename, self.mode, encoding='utf-8')
    return self.file

  def __exit__(self, exc_type, exc_value, exc_traceback):
    self.file.close()

with FileManager("my_file.txt", "r") as f:
  print(f.read())

And following for another example on how to create custom ContextManager for dealing with mongo database:

from pymongo import MongoClient

class MongoDBManager():
  def __init__(self, hostname: str, port: str):
    self.hostname = hostname
    self.port = port
    self.connection = None

  def __enter__(self):
    self.connection = MongoClient(self.hostname, self.port)
    return self.connection

  def __exit__(self, exc_type, exc_value, exc_traceback):
    self.connection.close()

with MongoDBManager('localhost', '27017') as mongo:
  collection = mongo.connection.TestDb.test
  data = collection.find({"_id": 1})
  print(data.get('name'))

The next big thing which is coming up soon as you might guessed already: Asynchronous Programming :-).
→ Stay tuned…

Hopefully it’s not that late now to write the last part of my DDD blog series. For those of You whom somehow got into this part without any chance to have a look into the other parts, You can check them out by starting from here.

ES (Event-Sourcing) and CQRS (Command-Query-Responsibility-Segregation) are not the new kids on the block. They have been there for some couple years. As for me, the first time I heard about these stuff was go back in the year of 2012. Even during that time I also knew that both (particularly ES) had been there for … not sure when exactly. Since then, I’ve been getting a chance to playing with these two “guys” several times, and lucky enough to failed several times as well :-). I always believe that from failures, we can learn so many good things about why they failed, which eventually can bring us to the next level of better understanding. That’s why as a good engineer and architect, we used to do ‘trial and error’ anyway. Even some of the great leaders from a well-known Companies won’t argue me on this matter :-) (See it here).

Back to our main topic, I won’t talk too much the nitty-gritty details about what are ES and CQRS ?, how are they working together to achieve their goals ?, and what are the benefits and drawbacks of using both ? particularly in our micro-services architecture. Nowadays you can find a lot of information about those two from the internet. However, I’d like to share that both actually came from different perspective and coined by different guy. I figured out that ES itself was brought from the concept of a “Journal Entry” in the “Accounting” world. So essentially, You can use CQRS without ES at all (even in monolith application), and similarly you can use optionally choose to implement ES without CQRS at all. However, there’s a saying that “You have to implement CQRS when you’re doing ES to make it easier”. This saying most likely came from someone that already tried to implement ES without CQRS, so they know exactly how difficult it is to use ES with “No CQRS”.

I had a chance to use CQRS several times in my non-ES architecture, yet I straightly use ES and CQRS together for my ES implementation due to that wise saying since I don’t want to reinvent the wheel.

With that being said, I will be using Java for our implementation since there’s one cool framework named Axon which already handled all of the technical complexities for us, so we can keep focus with the business functionalities to reduce our time-to-market. I’m planning to write another article later to discuss on how we do implement this ES-CQRS without any framework at all (i.e. build our own framework). But let’s use Axon for now.

As we can see from its’ website, Axon mainly comes with 2 different flavors: the Axon Framework, and the Axon Server which is used as it’s main event-store and message bus (command-bus and event-bus).

If we are searching for the tutorial on how to use this framework, you can find a lot of articles and even YouTube videos. So I think, it won’t be interesting for me to write another article for it. As a contrary, what I’m going to write here was based on my RnD in using this framework without Axon Server at all (we’ll be using PostgresDB as both our command-bus and event-store, and RabbitMQ as our event-bus). In other words, we won’t go with the Axon standard implementation. I was experiencing quite tremendous time to go with this implementation since all of the tips written on the official Axon website were not working as I expected, at least at the time when I’m writing this.

Enough the chit-chat, let’s discuss now on how we’re going to implement this.

Prerequisites

1. Java 11 (as the project that I’m actively working at the moment uses this version).
2. SpringBoot Initializr (https://start.spring.io).
3. I’m using this freakingly awesome IDE, yet any editor should be fine.
4. Docker. This one is optional, but I strongly recommend You to use it, especially if you want your machine to be not disrupted by any software installation. The most notably benefit by using it is we can easily switch between different version of software as we need due to its’ isolated environment.

Our Project Design

For simplicity in showing the concept, we’re going to build a simple user-management-service with two basic features as depicted below:

And based on the Onion Architecture that I had described on the Part 3, here’s what it looks like for our code scaffolding (structure components):

As depicted in the diagram, there’s no Axon server at all, and as replacement we’ll be using these following:

1. PostgresDB as our User Event Store, and implicitly as our Command-Bus to dispatch all commands to their respective command handler components (aggregates). This will be representing our writer database (the command side).
2. RabbitMQ as our Event Broker, hence all generated events will be routed to its listeners through this particular component. (We can use Kafka as well for sure, I will cover it later in the next chapter).
3. PostgresDB as our User Query Store to store all projections as needed from the business (functional) point-of-view. This will be representing our read database (the query side).

Create Our Project

Common way to start creating our project is by generating the project through Spring Initializr. For some Java IDE such as IntelliJ IDEA Ultimate, we can create it from there as well. I won’t go details on this since its very straightforward. What I’m going to describe here is that we’re going to have 1 parent pom project with 3 submodules inside respectively for:

1. User Core (usercore)
   This will be our core domain as represented on the above diagram. As you probably noticed, we have all of our events defined here. The main reason for it because events are something related and specific to the business domain, hence from the onion architecture perspective we have to cover it in the most inner side. And the reason for me to wrap this as an independent submodule is because we can deliver this as a Jar library to be shared later to any systems/parties that have an interest to integrate with our business domain.
2. User Command Service (usercmdsvc)
   No need for more explanation, as You might probably guess.. this is going to be our Command (writer) service, that is letter C from the CQRS perspective.
3. User Query Service (userquerysvc)
   Our Query (reader) service, that is letter Q from the CQRS perspective.

Creating our User Core Module

We only need to have lombok as our dependency for this particular module since this module will merely contains some POJO classes for our Domain Event and Entity, and we want to avoid any boilerplate codes such as getters and setters to produce much cleaner code.

Here’s what our pom.xml will be looked like after we create our first module for User Core:

Creating our User Command Service

Similarly, you can fire up another Spring Initializer and create our second module for Command service. And here’s our pom.xml for this particular command service module:

Here are some notably dependencies along with their explanation:

1. Spring Web
   artifact: org.springframework.boot.spring-boot-starter-web
   We’re going to expose our API as REST APIs. This is where this particular dependency play its’ role.
2. Spring Data JPA
   artifact: org.springframework.boot.spring-boot-starter-data-jpa
   We’re going to use SQL database as our main event-store, that’s the reason we added this dependency for all JPA operation.
3. PostgreSQL Driver
   artifact: org.postgresql.postgresql
   SpringBoot brings the concept of “convention over configuration”, therefore once it detects we have JPA library as one of our dependency, it strongly needs more specific information about what kind of database we’re going to use. Hence we must add this postgresql library (depends on our database) as our database driver, or Spring will be complaining later if we don’t specify any database driver within our pom.
4. Axon Spring Boot Starter
   artifact: org.axonframework.axon-spring-boot-starter
   Our main library for Axon framework. However, we need to exclude axon server connector as specified in the exclude tags, because we’re not going to use Axon Server.
5. Spring Cloud Stream Binder Rabbit
   artifact: org.springframework.cloud.spring-cloud-stream-binder-rabbit
   We need this library since we use RabbitMQ as our event-broker. Spring Cloud Stream is very handy since it is agnostic, so in essence we can use it to connect with any messaging middleware.
   In our case, we use Rabbit as our binder, so Spring will provide Rabbits’ specific implementation for us.
   In the future, if we need to change our messaging middleware to something else like Kafka, we merely need to replace our Rabbit binder with Kafka binder, and the rest of our code will almost still the same.
6. User Core
   This is our first module which we created earlier. We need to include it in our command service since we’re going to use some the domain events and entities from this particular core module.
7. Lombok
   To reduce any boilerplate codes.

Creating our User Query Service

Here’s our pom.xml for User Query Service:

As we can see, we’ve also excluded the Axon server connector from this user query service pom.xml. Another thing which make it different from the user command service pom is that instead of using Spring Cloud Stream, we deliberately use AXON AMQP extension to connect our event handler (listener) to our RabbitMQ. Nonetheless, you can also use Spring Cloud Stream as well. It all depends on You, which one is more convenience for You.

Creating our Parent Project

1. Create a new standard Maven project and give it a name as user-management-service (you can skip the archetype selection). You can either use your favorite IDE for this, or simply by executing this following command from your terminal:
   mvn archetype:generate -DgroupId=com.power \
   -DartifactId=user-management-service \
   -Dversion=1.0.0 -DinteractiveMode=false
2. Once the project is created, you can delete the src folder since it’s not needed.
3. Move the 3 modules you created earlier (usercore, usercmdsvc, userquerysvc) into this user-management-service folder.
4. Update your user-management-service pom.xml to Introduce those 3 modules we created earlier:

At this point, your project will be looked more or less like this one:

OK, that’s all for the setup. I won’t be going further with the explanation since it’s quite explanatory from the code that you can grab from my GitHub here. Please follow my GitHub account so you’ll get notified for any future update in the code, and feel free to drop me a message in case you have some concerns or constructive feedbacks.

Code Implementation

I’ve just realized that it’s been almost 2 years passed since I wrote DDD Part IV. I’ve been waiting all these times to write this part. Hopefully, this part will be useful for you, at least for me since i believe that the most effective way to tie your knowledge is by writing and sharing it.

Some of you whom probably have read my previous series on the DDD, might realized that deliberately i changed a bit the story’s sequences. This was because i got few messages asked me to give the code sample [talk is cheap, show me the code ~ Linus Torvalds] :-). Therefore, i’ll keep the ES and CQRS section for the last part. Another thing, I’ll be using go (golang) here since i’ve been working with it lately. The version that i’m currently working on while writing this article is 1.13.4.

So, let’s get started…

For the code implementation, i’m gonna start by implementing some of the functionalities within shopping cart since it’s pretty straightforward. I believe nowadays everyone knows about how it works (at least most of us ever bought something online).

First and foremost i’m gonna show you below the common processes of shopping cart. Note that what i’ll be showing here is restricted to thebounded context of the shopping cart, means we’ll just focus with the process of how the user/buyer choose the item and adding that particular item into his cart, subsequently continue with checkout. As for the billing/payment part, that will be in the bounded context of payment service. (if you’re neither really familiar nor confidence with what bounded context is, i would suggest you to read the first part here.

Worth to mention here, what are highlighted in the grey color were standing outside of our shopping cart bounded context. Hence, we won’t tackle the nitty gritty details of those objects within our code implementation since those things would be in other services (e.g. product catalogue service and user service). Nevertheless, we’ll still be having those objects within our code, in the context of what our shopping cart needs. For instance, we won’t need user credentials information in our shopping cart since that should be catered from the user service context. In essence, we merely need user information which is related to the shopping cart itself, such as: user_session_id, shipping address, billing address (furthermore, address information should also be catered from another service, e.g. : address service even this can be optional).

Another thing, i won’t be exactly using the onion architecture here. I’ll be using the clean code architecture instead as promoted by Robert C.Martin a.k.a. Uncle Bob. IMHO both are quite similar.., they just have different terms to explain the structure of their layers. Nevertheless, i often use all terms from those two architecture interchangeably inside the code. So, don’t get confuse with it.., just trying to focus with the layered architecture and also couple things from these following rules:

• Dependency between layer should be going inward in one direction. As far as i concern, it was designed like this to avoid any circular dependencies.
• A layer should depend only on one direct layer (one level) beneath it, it shouldn’t know any layers beyond that level. For instance, Aon B ( A →B ), and B depends on C( B →C ), yet A shouldn’t know anything about C.
• Each layer should depends upon abstraction ( interface ) rather than implementation. This complies with what Uncle Bob said about 2 rules to fix RFI issues, you can read it from my old blog here.

Let’s start by looking on some DDD basic building blocks for our shopping cart as depicted above.

According to what i wrote here, there are some technical building blocks within DDD, i.e. Entity, Value Object, Aggregate, Repository, and so forth. You can visit that link again to clarify the differences between all those things. Not all of those things are needed when we’re starting to implement our code, so just stick what we need based on the case (YAGNI).

First thing first, let’s create our project folder from the terminal and also initialize the go module as shown below:

Next step is by creating our pkg directory (mkdir pkg) from the same terminal. This pkg directory will contain our implementation logic for the shopping cart which complies with the clean code architecture we’re discussing here.

So here’s our project structure looks like for now:

In terms of the clean code architecture, by referring to the depicted shopping cart process diagram, we’ll be having these following entities within our code:

• User (this also represents a Buyer in theshopping cart bounded context, i.e. not all information need to be revealed here)
• Cart
• Product (used as a placeholder for the product information. And for the sake of simplicity…, we won’t have any product categories because our goal here merely to discuss DDD with Clean Code Architecture).

So, i create those 3entities within my pkg/domain/entity folder. To keep it simple, i have marked all of the fields as exported fields (later on, we can think about hiding the fields information behind the setter / getter which commons in Java).

And our value objects ( pkg/domain/valueobject ):

• Cart Items (strongly related to product entity which the details information should be fetched from the product catalogue service, and this is beyond of what we’re discussing here).
• Buyer Address (comprises of Billing and Shipping addresses, determined by the Address Type)

And our enum objects under sharedkernel/enum directory as following:

If you’re wondering about what shared kernel is, you can read it from my first part here.

The next important thing to do is to implement our core business logic (a.k.a. core domain in Onion Architecture). This is something that is related to the enterprise business rules out of the application service rule.

In order to implement this kinda thing, we need to setup our aggregate root (i call it as user_cart aggregate). Again, take a look at what i wrote here if you’re still wondering what is the aggregate all about.

Another to-do thing is to setup our repositories. Bear in mind, that when we’re talking about repository, it’s not always about the database. The storage implementation could be anything such as: web services, file, in-memory, etc.., and they should be abstracted by following some contracts defined on the interface. In that way, we can use them interchangeably later since we make our client code depends on the interface rather than directly on the implementation. In order to make it possible, we should start by abstracting our repositories with interfaces such as following:

I would assume that some of you will be asking me about those empty interfaces :-). Why do they exist ? Why do we use them ?.

As far as i concern, we’ll be having different models for every layer in order to make our architecture more loosely-coupled. In that case, we should abstract our interface model as far as we can, thus we can have more flexibility within our code. Let’s say for the user repository interface, we can have 2 implementations for it, one implementation to get the user information from the database, and another one to get the information from a web service (e.g. REST). Therefore, definitely we’ll have 2 models here, one based on the database model, and another one is based on the web response model. That’s the reason why we use empty interface ( interface{}) within our repository interface. You get it right ? :-). Don’t worry, everything will become clear once we implement our interface.

For the sake of simplicity, i’m going to implement in-memory repository for now since our first goal is merely to discuss about how’s our clean code architecture will be looked like. However, i will do as I can to incrementally update the code later for another storage / repository, such as database or web service. Feel free to follow my account on GitHub for this.

Let’s start to implement our repository interface by creating another directory (outside the domaindirectory, but still inside the pkg directory) as shown below:

And here are our models (inside the pkg/adapter/repository/inmem/model directory) to be used in the context of our in-memory repository (remember about what i explained earlier about the interface{} ,when we designed our repository contract interface)

followed by our in-memory repository implementation for those 3 models respectively (inside. /adapter/repository/inmem directory):

And the use cases for the cart and user as written below :

Last but not least, let’s create a small CLI program to test our shopping cart functionalities that we’ve created so far.

Ok, some of you might get overwhelmed with all of the code here (while some of you might not), especially in regards with the use case port and interactor (what would be the differences between those 2 ?). Hopefully it will be cleared soon.

Meanwhile, here’s our project structure looks like so far:

And here’s when we’re running and testing our CLI program:

You can grab the full code here. Again, feel free to follow my GitHub account so you won’t be missing any update that I made in the code :-).

Let me know for any concerns or questions from you folks :-).
Read the next part here.

Any comments or suggests would be well appreciated.

I’ve been working with Java for about 14 years now, and the last 2 years i’ve also worked with NodeJS and Golang to build some middleware AI platforms for my Startup. Nevertheless, i often push myself in learning other technologies as well. I’ve been learning Python these past few weeks. I was inspired by its concise syntax and the prominent feature that supports almost anything. You can use Python for any GUI and/or web development, operating system shell, data processing and analysis (data science), etc. Someone said that you can build the world with Python :-). Mmmmm, sounds interesting.

Since i believe that the best way to grasp the knowledge is to write what i’ve learned, so i’m gonna try here to write everything i know so far about Python.
I have read from different books and websites, here i’m trying to summarize within 5 parts everything i got from those different resources. Hopefully, you would find this article useful, especially for those of you who’s trying to learn Python in a crash course.

As the title implied, this is the first part of my journey, and I’m thinking to write my journey within these following series:

1. Python 3 Introduction → you are here
2. Python 3 More Advanced Concepts
3. Develop your First Micro-service (coming soon)
4. Python for Data Enthusiast (coming soon)
5. Utilizing Generative AI (LLM) for building an AI-based Application (coming soon)

and each series contains several sections.

Please take a note that all of the aforementioned parts were designed to be barely enough for you to learn Python fast within few days or weeks and we’re targeting that once you reached the final parts, you’ll be able to build your AI-based application that utilizes GenAI (LLM) underneath :-).

Python 3 Introduction

This part will contain these following sections:

1. What Python is and which version should i use ?
2. Installing Python
3. Package/Module (dependency) Management
4. What IDE (editor) to use
5. General Syntax and Semantics
6. IO Operation in Python
7. Package and Module System in Python
8. Best practice to start/manage your project
9. Sample Console App

Enough the chit-chat and lets start with the first section :-).

What Python is and which version should i use ?

I won’t go details here since you can find many articles that explain about this. Shortly, i’d like to say that for those of you whom just started to learn python now (as i do), better to use Python 3 since it is the latest version and widely used now.

Installing Python

I believe that there are many resources out there to explain this installation process. So.. go ahead and grab it.

Package/Module (dependency) Management

Just like Java, Python also has package/module manager to install/import the module you need from the online repository. Even there are two tools you can use for this particular purpose (i.e. setuptools and pip), but I found that the easiest way to install the module you need was by using pip (i concluded that pip has superseded setuptools).

The pip is going to download the package from PyPI (Python Package Index), and then add it to your Python installation. From that point on, every Python script that you have on your system will have access to that particular package. Yet, please beware that different version can cause trouble to your application, especially if you have similar package (in different version) used within your different applications. For instance, lets say you have a complete web application using version 0.11 of Flask, and then you create another web application that is using version 0.12 of Flask. In this case, your second web application is running well, but unfortunately most likely it will break your older (first) application since it was expected to run with version 0.11 of Flask. You got the point right ? it would be ideal if you can install two different Flask versions for those two web applications respectively.

To address the issue of maintaining different versions of packages for different applications, Python has introduced the concept of virtual environments.
A virtual environment is a complete copy of the Python interpreter. When you install package in a virtual environment, the global (system-wide) Python interpreter is not affected, only the copy is. Therefore, the solution for you to have different package versions for different applications is by creating a different virtual environment for every application you have. Virtual environments also added the benefit that they are owned by the user who creates them, so they do not require an administrator account.

There are few ways to prepare your virtual environment. For me.. i used to prepare my virtual environment through these steps (all of the steps below were executed on the terminal) :

1. Create your directory project and go into it.
2. Create the virtual environment: virtualenv -p python3 venv
3. Activate the virtual environment : source venv/bin/activate

That’s all :-). For those of you whom still a bit confused, i captured my screen as depicted below:

There are something that i’d like to highlight here. First, venv is the newly created directory that contains your isolated python environment (yeap, you’re right… this is your new virtual environment, though you don’t have to named it venv. You can give it any arbitrary name). Second thing, if you get an unrecognized command when trying to execute virtualenv, that means you need to grab it first through this following command from within your terminal:

pip3 install virtualenv

What IDE (editor) to use

There are many options for this one, but i would recommend either VisualStudio Code or PyCharm.

General Syntax and Semantics

Though you could find many resources about this one, but i’d like to recap some of those here. Hopefully, this will make you “dangerous enough” to start your journey as a Python developer after reading this blog series.

• Basic Data Types

Python basic data types has nothing different with most basic data types in other programming languages. In general, you will find strings, numeric, and boolean values for Python Basic Data Types. Furthermore, numeric can be divided into an integer (int) and floating point (float). There is also complex data type (i.e. combination of real and imaginary numbers), but this kind of type is rarely used.

To define a string in Python, you can either surrounded it by using single-quote (’’) or double-quotes (””). Here’s the example:

hero = 'Yauri Attamimi'

msg = "Yauri isn't coming today"

I’d like to explain few things here. First thing first, in order to define a variable in Python, you just need to specify a variable name (e.g. hero and msg) followed by an assignment operator (=) and the content/value of the variable.

Second thing regarding the above string definition, either way should be okay, yet sometimes it would depend on the content of your string value. For instance, in msg variable, we have enclosed the string value within the double-quotes (””) since the string’s content has a single-quote (’) in it.

Last but not least, important to know that Python is a dynamic typed (contrast with strongly-typed programming like Java), thus you can assign any arbitrary type to a variable. For instance, you can assign different types within one variable as you can see below:

Shortly, other types can be explained below:

# an integer value
rank = 9 

# a float value
fee = 7500.50

# a boolean value (True | False) 
# note the uppercase letter! 
is_success = True

• Operator

There are several basic operators in Python. I only show you here what are mostly used within your daily activities.

• Composite Data Types

Python has 3 mostly used composite data types as described below:

""" List """
members = ["Yauri", "Azizi", "Fadzlan"]

""" Tuple """
members = ("Yauri", "Azizi", "Fadzlan")

""" Dictionary """
{
   "id": 1,
   "name": "Yauri Attamimi",
}

""" Combination of List and Dictionary """
members = [
   {"id": 1, "name": "Yauri Attamimi" }, 
   {"id": 2, "name": "Azizi"}, 
   {"id": 3, "name": "Fadzlan"}
]

What make it different between list and tuple is that tuple is read-only (you can’t change once you created it), while list is writable thus you can modify the list with its built-in methods. Here’s the example:

# Define and yield a new list of members 
members = ["Yauri", "Azizi", "Fadzlan"]
print(members)

# append a new member into members, then yield
members.append("Joe")
print(members)

# remove a member from the list
members.remove("Joe")

You could find other list built-in methods from the Python 3 official documentation.

• Iteration

There are 2 types of iteration in Python 3: while loop and forloop as described below:

# While Loop
x = 1
sum = 0
while x <= 10:
   sum += x
   x += 1

print(f'sum = {sum}') 

as you can see, initially we defined a variable x with value 1, then we iterate through the while statement with condition x <= 10(i.e. the block statement inside a while will be executing repeatedly as long as the value of x is less than or equal to 10, thus you must not forget to increment the x value at the end of while block statement or else it will be looping forever). One important thing here as you might noticed already, In Python… instead of defining a block statement inside a curly braces ( { }) like in other programming languages (e.g. Java, C, etc), Python prefers to has an indentation over curly braces. That’s why you need to explicitly give an indentation to every statements that you’d like to put inside a block statement as shown above.

# For Loop
sum = 0
for x in range(1, 10):
    sum += x

print(f'sum = {sum}')

for statement in Python differs from what you might used in other programming languages like Java. Python’s for statement iterates over the items of any sequence (a list or a string). Do you read it ? yes, a string. You can also iterates over a string or list like these:

# Iterates over a list
members = ["Yauri", "Wu Ji", "Oyama"]
for name in members:
   print(name)

# Iterates over a string
greetings = "Good Morning"
for item in greetings:
   print(item)

• Conditional Statements

Perhaps, the most well-known and widely used for this kind of statement is the if statement as shown below:

# if statement
greeting = "Good Morning"
if is_morning:
   print(greeting)

# if else statement
if is_morning:
   print(greeting)
else
   print("Have a good day for you!")

# if else if statement
if is_morning:
   print(greeting)
elif not is_morning:
   print("Have a good day for you!")
else:
   print("I don't know what to say...")

• Function

I believe that most of you know about function. Just to recap again, function is a block of statements (organized code) that is reusable, and is often used to perform a single action (it better be !).

Function provides better modularity of your application !!

Here’s how to define and calling functions:

def calculate_order(total_cost, shipping_cost):
    return total_cost + shipping_cost

def print_total_order(): 
    # call calculate_order function 
    total_order = calculate_order(2000, 75) 
    # print the result to console
    print(f'Your total order: {total_order}')

# call print_total_order function
print_total_order()

As you see, you define a function by using keyword def. And the function body is written within a block statement (i.e. indicated by an indentation).

The naming convention used for a “function name” in Python is similar with the naming convention for a “variable name”, i.e. all written in lowercase, separated with an underscore (_)if has more than one word.

• Exception

Exception is a way to catch any error thrown from your program. Your program might be syntactically correct, but sometimes error might happen within your program. Consider the following code snippet:

x = 2 / a
print(x)

if you run that code, and somehow a is equal to zero (0), then you’ll obviously get the following error:

and most of the case, the program will unexpectedly stop to run (crash).

In order to address that kind of situation, you’ll need to wrap those line of codes (which potentially cause an error) inside a try..exceptblock as shown below:

try:
   x = 5 / 0
except ZeroDivisionError:
   print('cannot divide a number with zero!')
else:
   print(x)

So if you run the program again, it will nicely print a friendly message as shown below:

and the program will still continue running. Everyone is happy :-).

IO Operation in Python

There are many IO operations in Python, yet I will merely discuss here about input operation in the context of get an input from console and print an output to console, since this is what we need for our last section when we discuss about our console app application.

Read my short explanation below as usual (example of code):

# get a string input from a keyboard (within terminal)
name = input("Enter your name: ")

# print to console (terminal)
print(f"Howdy {name} !")

One important thing here, every input will be treated as a string by default, hence if you’d like to dealing with it in another data type such as an integer, you’ll need to cast the type as shown below:

# get an integer input from a keyboard (within terminal)
level = int(input("Enter your game level: "))

# print to console (terminal)
print(f"Game Level: {level}")

Package and Module System in Python

In Python, a sub-directory that includes a __init__.py file is considered as a package and can be imported. The __init__.py file is used to define what symbols are exposed by the package to the outside world. So when you import a package, the python interpreter will try to find and execute the __init__.py implicitly.

Here’s how to define a package (named utils):

as depicted on the above image, we also created file converter.py inside our new utils package. Here’s the source:

And here’s the various ways that can be used to import that particular package (hopefully quite explanatory for you ^_^):

# First Technique 
from utils import converter

print(converter.lbs_to_kg(165)) 
print(converter.kg_to_lbs(71.5))

# Second Technique
from utils.converter import lbs_to_kg, kg_to_lbs

print(lbs_to_kg(165))
print(kg_to_lbs(71.5))

# Third Technique
from utils.converter import lbs_to_kg as ptkg
from utils.converter import kg_to_lbs as kgtp

print(ptkg(165))
print(kgtp(71.5))

Best practice to start/manage your project

There are several best practices to maintain your project. First and foremost… as discussed previously in the point number three (package/module management), the best way to start your project is by creating a virtual environment for it, thus you’ll have a freedom to manage your package versions without affecting your global Python’s interpreter.

As you can see, you can use virtualenv command to create the virtual environment from within your project folder.
And since Python 3, there is a built-in virtual environment included. Thus, instead of using virtualenvcommand as shown above, you can also use this following command:

python3 -m venv myfirstp3env

Regardless of the method you used to create it from those aforementioned commands, you will have a virtual environment inside your project folder, which is represented as a folder with the name you’ve choosen before (i.e. venv in this case) where the virtual environment files are stored.

Note that in some operating systems you may need to use python instead of python3 in the command above. Some installations use python for Python 2.x releases and python3 for the 3.x releases, while others map python to the 3.x releases.

Once you have your virtual environment within the project, don’t forget to tell the system that you’re going to use it by activating it.

When you activate a virtual environment, the configuration of your terminal session is modified so that the Python interpreter stored inside the virtual environment is the one that is invoked when you type python. The terminal prompt is also modified to include the name of the activated virtual environment, i.e. (venv) p3journey1in this case. Note that all changes made to your terminal session are temporary and private to that session, so it won’t persist when you close the terminal.

After created the virtual environment for your project, the next point is to ensure that you manage your project source files in term of packages. So, the application will exist in a package. (See point number 6, Module System in Python).

Last but not least, if you were using other external libraries (other than built-in libraries from Python), don’t forget to freeze your libraries by using this following command:

pip freeze > requirements.txt

This will be listing all of your dependency libraries (incl. the version) within requirements.txt file. Consider this file same as a package.json (in NodeJS) or pom.xml (in Maven).

And don’t forget to skip/ignore your virtual environment folder from your repository. You can add/configure it by adding the folder name (venv in our case) into our .gitignore file (if you’re using Git).

That’s all of the best practices i found useful, at least for now :-).

Sample Console App

For our basic sample app, we’ll be creating a simple console application that asking a user to enter some basic informations such as their first name, last name, and weight (kgs or lbs). Subsequently, the console will display a healthy menu (including price) and asking you to choose which menu you’d like to order. Finally, the program will proceed to checkout order and asking you to pay some amount (the total cost will be displayed on the screen).

You can grab the sample code here.

That’s all for now, hope you like it and wait for the next part when we’ll be discussing about more advanced topics such as OOP in Python, Logging, Decorator, Generator, and some Python 3 distinctive features. Stay tuned :-)

Any comments or suggests would be well appreciated.

(originally published on Dzone)

Finally, I got a chance to write the fourth part! For those of you who didn’t get the chance to read the previous parts, you can read them by starting on Part 1 here.

Now.. within this part, I will try to elaborate on the microservices architecture and its relationship with Domain Driven Design (DDD).

Microservices Architecture

First things first: let’s describe what microservices architecture is all about.

Microservices architecture is a kind of an architectural pattern that focuses on developing/building small, reusable, and scalable services. Microservices allow us to break our large system into a number of independent collaborating processes, thus it can help to avoid a big monolith application, which is difficult to maintain, especially if you have big projects with a big team.

Microservices also can be very useful when you have to create services for polyglot devices such as wearables, Internet of Things (IoT), mobile, desktop, and web.

Microservices itself is not a new term. It was coined in 2005 by Dr. Peter Rodgers, who mentioned micro web services based on SOAP. It has become more popular since 2010.

The keys to microservices architecture are:

1. It is independently deployable in terms of stack, framework, and/or languages used.
2. It is deployed as a small service that keeps focusing on doing one thing well, i.e. domain-driven services.
3. Well-defined interfaces and minimal functionality.
4. Avoiding cascading failures and synchronous calls — reactive designing for failure.
5. Every service has its own data and uses events/messages to communicate with other services.
6. Every service is deployed independently and isolated from other services (usually running in its own container) and automatically scalable.

The main goal is to provide you with a small set of independent services which run independently in different environments, but can communicate with each other (tight cohesion). As we know, coupling is a two-headed beast. On one side, tightly-coupled code is difficult to test, difficult to maintain/reuse, and typically exhibits “whack-a-mole” bug behavior (i.e. fixing one bug most likely will produce one or more new bugs). On the other side, a certain amount of coupling is also necessary since completely uncoupled code doesn’t do anything; thus, coupling is necessary but should be carefully managed. This is what we call “Loosely Coupled, Highly/Tightly Cohesive.”

Microservices Benefits

1. Easy to scale as individual components.
2. Easy to deploy and reduce time deployment, i.e. you can deploy each module without interrupting any other module.
3. Easy to maintain due to its smaller code size, and you can have a small, focused team.

Microservices Challenges

1. It’s difficult to achieve strong consistency in distributed services.
2. It’s harder to debug and trace issues compared to monolithic applications.

There are many other challenges that you will know yourself later, once you implement microservices. Nevertheless, it will depend on how you design and manage your microservices by following some well-known best practices, like API Management, Traffic Management, Services Monitoring, etc. I’ll try to encapsulate them later in another series, if I get the chance.

How Does DDD Relate to Microservices?

As mentioned earlier, in microservices, we build each service to serve only one thing and do one thing well. Each service is also isolated from the others. On this matter, DDD principles can help us to keep the scope of the service small through what it calls “bounded context.”

Subsequently, DDD is going to help you investigate and know your domain and all subdomains well through the communication you build with the domain experts. By knowing your domain and subdomains well, you will know the map contexts and how all subdomains interact with each other, which will help you in designing and choosing the type of your microservices architecture and what kind of approaches you use to implement them, whether a reactive approach, orchestration approach, or hybrid… it will depend on your knowledge about the domain you’re working on. There are pros and cons for each approach that need to be evaluated based on the project and your domain knowledge. DDD will help you make a decision on this matter.

That’s all for now… please let me know if you have any more insight into how DDD relates to microservices!

Read the next part here.

Any comments or suggests would be well appreciated.

This is the third part of my DDD series. I encourage you to read the first part and second part before going further on this particular part.

Within this particular part, i’ll be talking about one of my favorite architecture called “Onion Architecture”. Nevertheless, allow me to recap first about what do we have so far about DDD as following:

DDD is all about how we design our software from the business perspective, not from the technical perspective. For that purpose, we must go together with the domain expert (a.k.a business expert) during the design process, thus we can keep align with the business want. The process always start with what we call as ubiquitous language (i.e. we need to have standard term to be used along with the design and implementation process). Subsequently, break the complex domain into smaller sub-domain known as bounded context and carefully define the boundaries and contract used to communicate between the individual bounded context. So each bounded context appears as a black box to another (only care about the contract interface, no need to care about the implementation details since its hidden from the outside).

Additionally, there are some pitfalls that need to be avoided during the design and implementation. Those are data centric mindset when modeling the problem domain, focusing on implementation details such as entities, repositories, etc instead of the core concepts, generic and specific technical terms, and focus on DB transactions instead of business transactions.

Ok, let’s start with the main topic now, shall we :-).

Onion Architecture was coined by Jeffrey Palermo. If you ever heard about Hexagonal Architecture (a.k.a. Port and Adapters) from Alistair Cockburn, the idea of Onion Architecture actually was inspired from this Hexagonal Architecture. Whether it’s Onion, Hexagonal, or Clean-Code… they are similar in my opinion. What make them different were just the nomenclature and/or number of layers applied while you’re writing your code.

You don’t have to use Onion Architecture though you implement DDD. And you aren’t forced to use DDD as well in order to apply Onion Architecture. Both are independent each other. Therefore, you are free to use other than Onion Architecture for DDD (even traditional architecture such as MVC still fit in DDD). However, Onion Architecture is a strong candidate and suited for DDD.

What make Onion Architecture different with the Traditional one ? Lets see the traditional first and come up with Onion later.

In the traditional architecture, the application’s structure is comprises of three tier/layer such as depicted below:

As we can see, on this particular architecture each layer highly depends on the layers beneath it, and every layers normally will also dependent to some common infrastructures (e.g. frameworks or utility services). With this kind of architecture, it will be difficult to give a separation of concerns because of the created coupling between each layer (each layer is coupled to the layers below it, and each layer often coupled to various infrastructure concerns). Yeah, coupling is important in order to create the interaction between components in our system, but what i’m trying to say here is that this particular architecture creates unnecessary coupling.

For instance, let’s say the team had decided to use SpringBoot to build their microservices which represent the infrastructure layer. Subsequently, after couple years the team has decided to change the framework to another or perhaps just drop the SpringBoot. With this kind of architecture, it will be difficult to deploy the new framework without any adjustment (changes) in the other layers since each layer is highly coupled to the framework (infrastructure) layer. Thus, there will be a possibility for the team in breaking the current business layer which contains all of the business logic (business domain). Bear in mind that, a good system should have criteria MECE (Mutually Exclusive Comprehensively Exhaustive) a.k.a. “loosely coupled, highly cohesive”. Therefore, the more coupling you created in your system, there will be more effort you need to change the system and breaking it to small independent parts.

On the other side, the biggest offender (and most common) is the coupling of UI and business logic to the data access. Transitive dependencies are still dependencies. The UI won’t work if the business logic isn’t there, same as the business logic won’t work if the data access isn’t there. Data access changes frequently, and whenever the data access changed, you will also need to adjust / change the business layer with this particular architecture. And, did i mention before ? Changing the business layer which contains the business rule will have a big risk for the company, especially when the business already stable and the current system has widely used by the users in the Company.

Here’s why Onion Architecture come to the rescue :-). Take a look at the diagram below for the Onion Architecture.

There are lot aspects of Onion Architecture, but the main goal is how it controls the coupling. The basic rule that you need to bear in your mind is all coupling is toward the center. For instance in the depicted diagram we can say as follow:

1. The “Infrastructure” layer will know about the “Application Services”, “Domain Services”, and “Domain Model”.
2. The “Application Services” will know about the “Domain Services” and “Domain Model”.
3. The “Domain Services” only know about the “Domain Model”.
4. The “Domain Model” only know about itself.
5. The inner layer will not and should not know about the outer layer. Hence, the “Domain Model” doesn’t know about “Domain Services”, “Application Services”, and “Infrastructure” layer. Same as the “Domain Services” doesn’t know about the “Application Services” and “Infrastructure” layer, and so forth.

In the very center, we see the “Domain Model” which represents the state and behavior of the model for the Organization/Company (i.e. the application we’re trying to build). Around the domain model are other layers with more behavior where the number of the layers can be vary (i.e. no restriction of the number of the layers).

“Application Core” will glue all the layers like “Domain Model”, “Domain Services”, and “Application Services” (again, the numbers of the layers can be vary which means we can have more layers rather than just those 3 layers).

“Domain Model” is the very center, and since all coupling is toward the center, then the “Domain Model” must be coupled only to itself as mentioned before. Typically, the “Domain Model” consists collection of interfaces called Repository Interfaces those provide saving and retrieving mechanism for objects in the system. Thus, i can say that the “Domain Model” defines the contract of the object’s system behavior especially for saving and retrieving mechanisms. Remember, only the interfaces (not the implementation). We can leave the implementation later on different layers (i.e. the infrastructure layer).

The outer layer (i.e. “Infrastructure” layer) is reserved for things that frequently changed. These things should be isolated from the “Application Core”. UI, Automation Test, DatabaseAccess, NetworkAccess, FileAccess belongs to this “Infrastructure” layer.

That’s all folks. Read the next part here.

Any comments or suggests would be well appreciated.

It’s been a while since i wrote the first part of DDD series. Within this second part, i will continue with one of the most important thing of DDD before you’re going further with the implementation. First thing first, you must know about DDD building blocks as you can see below:

1. Entities
2. Value Objects
3. Aggregate Roots
4. Repositories
5. Factories
6. Services

Tighten your “seatbelt” :-). We’re going through the details of those aforementioned blocks now.

1. Entities

Entities (or “entity” in singular form) is a plain object that has an identity (ID) and potentially mutable. Each entity is uniquely identified by an ID rather than by an attribute, therefore two entities can be considered as equal (identifier equality) if both of them have the same ID, even though they have different attributes. This means the state of the entity can be changed anytime, but as long as two entities have the same ID, both are considered as equal regardless what attributes they have.

2. Value Objects

Value Objects are immutable. They have no identity (ID) like we found in Entity.
Two value objects can be considered as equal if both of them have the same type and the same attributes (applied to all of its attributes).
They are often uses for a thing like message passing and in fact they are particularly useful in the API layer within some layered architectures like Onion, Hexagonal, or Clean-Code Architecture to expose your domain concepts without necessarily expose the immutable aspect.

Some benefits of ValueObjects:
1. Compound of ValueObjects can swallow lots of computational complexity.
2. Entities can be released from logic complexity.
3. Improve extensibility, especially for testability and concurrency issues if using correctly.

3. Aggregate Roots

Aggregate root is an entity that binds together with other entities. Moreover, aggregate root is actually a part of aggregate (collection/cluster of associated objects that treated as a single unit for the purpose of data changes). Thus, each aggregate actually consists of an aggregate root and a boundary. For example, the relationship between Order and OrderLineItem within SalesOrder domain can be considered as an aggregate where Order acts as the aggregate Root, while the OrderLineItem is the child of Order within SalesOrder boundary.
One of the key features of an aggregate root is the external objects are not allowed to holds a reference to an aggregate root child entities. Thus if you need access to one of the aggregate root child entities (a.k.a aggregate), then you must go through the aggregate root (i.e. you can’t access the child directly).
The other thing is all operations in general within the domain should where possible go through an aggregate root. Factories, Repositories, and Services are some exceptions to this, but whenever possible, if you can create or require that an operation go through the aggregate root, that’s going to be better.

4. Repositories

Repositories are mostly used to deal with the storage. They are actually one of the most important concepts on the DDD because they have abstracted away a lot of the storage concerns (i.e. some form / mechanism of storage).
The repository implementation could be a file-based storage, or database (SQL / NoSQL based), or any other thing that is related with storage mechanism such as caching. Any combination of those are also possible.
Repository should not be confused with the data store. A repository job is to store aggregate roots. Underneath that, repositories implementation may actually have to talk to multiple different storage locations in order to construct the aggregates. Thus, a single aggregate root might be drawn from a REST API, as well as a database or files. You may wrap those in something called the data store, but the repository is sort of a further layer of an abstraction on top of all those individual data stores. Usually, i implement the repository as an interface within the domain/domain services layer within Onion-like Architecture (skip for now, gonna talk about this kind-of layered architecture later), and then the implementation logic of the repository interface is going to be defined in the infrastructure layer.

5. Factories

The factories are used to give an abstraction to the object construction (see Factory design pattern from GOF).
A factory can also potentially return an aggregate root or an entity or perhaps a value object.
Often times, when you need a factory method for an aggregate root, it will be rolled in to the repository. So your repository might have a finder create method on it.
Usually factory also implemented as an interface within the domain/domain services layer with the implementation logic defined in the infrastructure layer.

6. Services

A service is basically exist to provide a home for operations that don’t quite fit into an aggregate root. As an example, when you have an operation that you don’t know on which aggregate root it goes into, perhaps it operates on multiple aggregate roots or maybe it doesn’t belong to any existing aggregate root, then you can put the logic into a service. However, don’t be rush to put everything into a service. First and foremost, its better to carefully analyze whether the operation fits into one of the existing aggregate root or not. If you couldn’t find the aggregate root, subsequently better to ask your self in case you have missed one aggregate root or perhaps there are domain concepts that you haven’t considered that should be brought into your domain before you put the operation into a service.

Other Important Things

I often found that many developers use term VO (Value Objects) and DTO (Data Transfer Object) interchangeably. They consider both are just to be the same. This is quite annoying for me. In that case, i’d like to clarify here that both are refers to different things.
As depicted on the picture below, VO and DTO are subset of a POJO/POCO. Entity is also a subset of POJO/POCO.

In the above depiction, POJO and POCO can be interchangeably used. Both are refer to the similar thing. Both are just domain object that mostly represent the domain / business object within the business application.

The term POJO (Plain Old Java Object) was coined by Martin Fowler and very popular in Java community, while POCO (Plain Old CLR Object / Plain Old Class Object) is widely used in the dotNet.

As mentioned earlier, DTO, VO, and Entity are just a subset of POJO/POCO. However they are really different things as described below:

DTO is merely a stupid data container (only holds data without any logic). Thus, its anemic in general (only contains attributes and getter/setter). DTO is absolutely immutable. Usually we use DTO to transfer the object between layers and tiers in one single application or between application to application, or JVM to JVM (mostly useful between networks to reduce multiple network call).

VO is also immutable, but what make it different with DTO is that VO also contains logic.

That’s all for now. Read the next part here.

Any comments or suggests would be well appreciated.

(also published on https://dzone.com/articles/ddd-part-i-introduction)

The first time I heard about DDD (stands for Domain Driven Design, not D̶e̶a̶d̶l̶i̶n̶e̶ ̶D̶r̶i̶v̶e̶n̶ ̶D̶e̶s̶i̶g̶n̶ forsure), i was still working as a Senior Java Developer for Hewlett-Packard on its Development Center at Cyberjaya, Malaysia. I wasn’t quite interested with the topic since it was difficult to get a good resource during that time. Someone told me to find the Eric Evan’s book (“the blue book”), and gotcha..i got the book and added it to my PDF collection.

During this time, DDD is quite new (especially in Indonesia), thus only few companies have successfully implemented this new thing. And somehow IMO, i found that many DDD resources were too difficult to be grasped by most of the readers (i.e. they are too abstract and lack of good examples). Therefore, i’m planning to pick up this awesome topic and write it in a series, equipped with an application sample to be followed step by step.

This is the first part of other series as follow:

1. DDD Part I, Introduction → You are here
2. DDD Part II, DDD Building Blocks
3. DDD Part III, DDD and Onion Architecture
4. DDD Part IV, DDD and Microservices
5. DDD Part V, Code Implementation
6. DDD Part VI, ES and CQRS Implementation

In this first part of Introduction, i would like to start with some basic concepts as written below:

1. What is DDD all about ?
2. How do we get started ?
3. What should we avoid in DDD ?

Let’s get started :-).

1. What is DDD all about ?

To start this section, I’d rather took the definition from one of DDD community, that describes DDD (Domain Driven Design) as an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
As the definition implies, DDD is suitable for you if you’re building a software that has complexity on its business process (business domain). So, not every software is suitable for DDD (e.g.: a simple CRUD application doesn’t suitable for it since it’s not that complex).
Eventually, team work is very important within DDD since you need to keep in touch with the users/clients (a.k.a Domain Experts). Moreover, you build the software for them, not for you (you got the point right). Just like someone said: “the software can fail either in two ways, you build the things wrong or you build the wrong things”. In that case, you have to ensure that you understand correctly the business that you’re going to build. This is DDD all about.
To summarize, DDD can be described as a technique for developing software that focuses on collaboration between technical experts and domain experts. Therefore, we must keep focus with the domain experts instead of the nitty gritty details of the technical stuffs.

2. How do we get started ?

First thing first, as mentioned earlier, the big point is to keep in touch with the business/domain expert.

Following, i had recap several points those we can use as the guidance while we have discussion with the domain expert:

1. Learning about the problem domain, i.e. the specific problem the software you’re working on is trying to solve. Look at the big picture of the current business process.
2. Breaking the domain into smaller sub-domains.
3. Focusing on one sub-domain at a time with the domain expert, and always use ubiquitous language to define working out terminology.
4. Creating a bounded context between sub-domain (again, ubiquitous language should always be used throughout the bounded context, from conversations to code, in the diagram, on the whiteboard, in the design document, team discussion, etc. The point is to use the bounded context everywhere).
5. Ideally, there will be different team, codebase, and database for each bounded context.
6. Since everyone are working for their bounded context, so they are free to change anything within their context.
7. For all cross cutting concerns those are shared between bounded context (we call it shared kernel), any changes should be known and agreed between all team in every bounded context.
8. Always stay focus with the domain’s behaviors rather than domain’s state (favor rich model over anemic model).

To summarize, always use ubiquitous language (i.e. same terminology) across the team, break the domain into smaller subdomains and give an isolation (i.e. bounded context) by defining the boundary and think about how the subdomain within the bounded context can communicate to each other using interfaces / crafted software contract.

3. What should we avoid in DDD ?

On the other hand, during our DDD implementation, we need to be careful for certain practices those are too common among software developers. These are :

• Using data centric view when modeling the problem domain.

Usually data model is the first thing that an architect/developer would start to design. They always consider that data is the most important thing because data is all what we need to report. If you start with DDD, you must change this mindset. Data on its own is meaningless. Only logic gives data a meaning !!!, and the same data can have different meaning in different contexts. Therefore, we must start with context and logic instead of data.

• Focusing on implementation details like entities, value objects, services, factories, repositories, etc instead on the core concepts as discussed earlier.

Entities, value objects, repositories, and so forth don’t have a meaning until we defined the ubiquitous language, bounded contexts, and the interfaces / crafted software contract. If we start to early with the implementation details like entities, then it’s a good chance that the result would be an anemic domain surrounded by a lot of services and business logic scattered everywhere.

• Using generic and developer specific terms and concepts when implementing the application.

We should never use concepts like save, update, delete, handle, manage, etc. Those concepts are too technical or abstract concepts with no specific meaning. Instead, we must stay focus with the business concepts. Those aforementioned concepts (i.e. save, update, etc) are not related to business concepts. To understand this, i encourage myself to always imagine the client run his errands/business without computers (i.e. doing specific task manually). So, always think from the business/domain expert perspective, and give a clear context on it. Avoid generic term that can lead to different meaning in different context (i.e. use specific context).

• Finally overrating DB transactions instead of focusing on the business processes or transactions.

Within DDD, business transactions is more important than DB transactions. DB transaction is ACID, strongly consistent, and short running, while business transaction is not. In fact, in the real life, we don’t know about DB transaction, we just know about business transaction. For example, imagine when you sit in the restaurant and order some foods and/or beverages. Within the order transaction, realize it or not, there will be a process with some asynchronous tasks with many possible inconsistent state changes, even by the end all states will be consistent (eventually consistent). And this blackbox process is works, scalable and widely acceptable by everyone.

Therefore with DDD, do not ever think about DB transactions, instead always think about the real world process such as what the possible actions (behaviors), and their possible outcome or about how to compensate the actions if some failures occurred.

You don’t have to understand all the aforementioned points for now. I know that most application developers not too familiar with the idioms and peculiarities of those concepts. Just keep reading for now, and hopefully they will become clear when the other parts coming.

Read the next part here.