Domain Driven Design Onion Architecture with Django Rest Framework

Question

I have been reading recently about Domain Driven Design (DDD), I like the concept and especially the idea of Onion architecture goes with it (https://www.youtube.com/watch?v=pL9XeNjy_z4).

I am quite curious to understand how such an architecture we can implement with Django Rest Framework or in other words can we do DDD with Django rest framework in Onion arch style?

1. Is it possible to map the concepts in Onion architecture to DRF?
2. As frameworks like Apache isis (https://isis.apache.org/) do DDD by building Object Oriented UIs where users can directly interact with domain entities, how DRF can possibly do such things?

As an example I have writing DRF Code in following fashion:

In models.py I would have my models defined:

class Library(models.Model):
    library_id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=30)
    ...

    #This helps to print in admin interface
    def __str__(self):
        return u"%s" % (self.name)

In serializers.py I would have my model serializers:

class LibrarySerializer(serializers.ModelSerializer):
    class Meta:
        model = Library
        fields = '__all__'

I will have corresponding url in urls.py:

router.register(r'libraries', LibraryViewSet)

and in views.py performing CRUD operations:

class LibraryViewSet(viewsets.ModelViewSet):
    queryset = Library.objects.all()
    serializer_class = LibrarySerializer

How would that relate to (perhaps with appropriate modifications) to DDD/Onion architecture?

Deflected

Answer 1

Short answer: DRF and DDD+Hexagonal architecture are not the best friends.

When the model reflects the domain (the subject, problem at hand), it is most likely in the antipodes of a simple CRUD. Create, Read, Update, Delete are specific actions that will not always be part of your ubiquitous language.

Moreover, Onion/Hexagonal Architecture requires that the model does not depend on the framework or library code. To invert these dependencies and make the persistence and the delivery mechanism depend on your model instead is possible (i.e. not using any Django import inside your domain), but will certainly be uphill with Django. The framework is prescribing the opposite to all this.

Zlatoust

Answer 2

The idea of DDD is more about seperation of concerns. Seperating the logic from framework functionality is crucial, this is the case in any framework. if you you use persistance/ORM stuff from django that is fine but don't mix it up with your domain logic, always keep it seperate. The logic should also work with a different ORM. There should always be some kind of layer in between.

Unhealthy