'Large scale server application using DDD with Python? [closed]

We are preparing to build a large scale server application.

To model the logic effectively we're planning to use DDD, including the tactical patterns such as domain events, specifications, repositories and etc...

Is onion architecture applicable in Python? Are the abstraction abilities sufficient in Python?

Technically speaking:

I've done a little research and saw that there is no popular DI container and actually DI is considered a bad practice in Python, considering that DI is how I'm used to instantiating complex objects in the application layer it seems suspicious...

Architecturally speaking, There is no built in multithreading support in Python (CPython). The cooperative multithreading model offered by Python could be sufficient for single threaded architectures, with scale out options. or is it?

Are there more challenges and things worth considering before diving in?

The bottom line is : Did anyone have experience implementing a large scale enterprise application using DDD with Python? Or should we stick to .NET/Java and be on the safe side?



Solution 1:[1]

Not sure, but it sounds like you may be a new hire within this org coming from a java/.net shop ("...considering that DI is how i'm used to instantiating complex objects in the application layer it seems suspicious...).

Keep in mind

  • You can do DDD with clean design in almost any programming language.

  • Take a look at this video presented by Add Roll. Basically, the primary point being made is that solution scalability is determined by the architecture and design choices not the programming language or platform.

  • Also consider, Drop Box was built with Python and scaled to 1 million users before they ever considered any C-optimizations.

Net-net

From a product development perspective, you generally do not want to put any critical-path item at risk using a "new" technology. New can mean new to market or new to the team/org. In this case, based on the very first part of your post "We are a python shop ", I would at a minimum defer to your internal team's expertise and leverage your existing teams core competencies. Your project will have a much lower risk profile and achieve a quicker time to market versus retraining the staff to use another technology platform.

Solution 2:[2]

If you'll forgive (a) the shameless self-promotion and (b) resuscitating an old thread, my colleague Bob and I wrote a book all about doing DDD and DDD-adjacent "stuff" with Python:

https://www.cosmicpython.com/ (O'Reilly, but it's free to read online in its entirety)

to answer your questions:

  • Is onion architecture applicable in python? Are the abstraction abilities sufficient in python?

Absolutely. The book discusses ways of implementing Onion / Ports & Adapters / Clean architecture patterns. I'm taking the question about "abstraction abilities" to be a worry about Python's dynamic nature and lack of formal interfaces? But in fact those are no barrier. ABCs and the new typing.Protocol are there if you want something like interfaces, but you can get away without them.

  • I've done a little research and saw that there is no popular DI container and actually DI is considered a bad practice in Python

DI is sometimes viewed with some skepticism in the Python world, but I wouldn't say people think it's a bad practice per se. In the book we provide a bit of a defense, and talk about pros + cons, as well showing approaches to "rolling your own" DI (what Mark Seeman called "Pure DI" or "Poor Man's DI") as well as a couple of pointers to Python DI libraries

  • The bottom line is : Did anyone have experience implementing a large scale enterprise application using DDD with Python? Or should we stick to .NET/Java and be on the safe side?

We did, and it turned out fine! So if anyone out there is thinking about it, dive in and join in the fun! :-)

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Allan McLemore
Solution 2 hwjp