Python – DDD – Domain Driven Design, which development order should be applied

Architecturedomain-driven-designpython

1 – Design my entities, ie (in python):

class Account:
    def __init__(name, author):
        self.name = name
        self.email = email

2 – Design my repositories: (as interface)

class AccountRepository:
    def add(self, account):
        """ @type account Account """
        pass

    def find_by_name(self, name):
        pass

    def find_by_email(self, email):
        pass

    # remove, and others...

Now, I can go two ways:

A: Design and implement my domain services:

class SignUpService:
    def __init__(self, account_repository):
        """ @type account_repository AccountRepository """
        self._account_repository = account_repository

    def create_account(self, username, email):
        account = Account(username, email)
        self._account_repository.add(account)

    # other methods that uses the account_repository

B: Implement my Repositories Strategies:

class MongodbAccountRepository(AccountRepository):
    def __init__(self, mongodb_database):
        self._mongodb_database = mongodb_database

    def add(self, account):
        account_data = account.__dict__
        self._mongodb_database.accounts.insert(account_data)

    # and the other methods

Which is the correct order? and why? 1, 2, A, B or 1, 2, B, A?

Thank you so much!

Best Answer

Firstly I'd start off with the UI, thinking about the tasks/commands users need to perform and the data involved in each task/command. This is known as a Task-Based UI approach.

These tasks will form a 1-1 mapping with methods provided by the Application Services (different to a Domain Service).

Then I'd design my aggregates based on these tasks & data - an optimal design would be for one task/transaction (Application Service call) only involving one aggregate. To me, this is what designing aggregates based on behavior is all about.

I only implement Domain Services where a transaction needs to change state on more than one aggregate. These Domain Services abstract any logic away from the Application Service (who's job is only to orchestrate).

Storage would come last - you can only implement storage once you know exactly what you're storing?

So my full order is:

  1. UI

  2. Application Service (I call it a command service)

  3. Domain

  4. Aggregates

  5. Domain Service

  6. Storage

FYI I tend to follow the principals of CQRS so querying is also another 'layer' I need to consider, but I've just given the order in terms of DDD and designing aggregates.

On the subject of designing aggregates, I recommend the these articles by Vaughn Vernon

I also wrote a blog regarding designing aggregates based on behavior.

Related Topic