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?

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's most likely in the antipodes of CRUD. Create, Read, Update, Delete are actions that will not always be part of your ubiquitous language.

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