[wormlord]

> I have seen how dangerous it can be when inexperienced developers take it as a gospel and try to implement everything at once

This book explicitly tells you not to do this.

> Similarly, service layers and unit of work are useful when you have complex applications that cover multiple complex use cases; but in a system consisting of small services with narrow responsibilities they quickly become overly bloated using this pattern. And don't even get me started with dependency injection in Python.

I have found service layers and DI really helpful for writing functional programs. I have some complex image-processing scripts in Python that I can use as plug-ins with a distributed image processing service in Celery. Service layer and DI just takes code from:

```python

dependency.do_thing(params)

```

To:

```python

do_thing(dependency, params)

```

Which ends up being a lot more testable. I can run image processing tasks in a live deployment with all of their I/O mocked, or I can run real image processing tasks on a mocked version of Celery. This lets me test all my different functions end-to-end before I ever do a full deploy. Also using the Result type with service layer has helped me propagate relevant error information back to the web client without crashing the program, since the failure modes are all handled in their specific service layer function.

[wbc]

may I ask how you're mocking Celery to test?

the two main methods I've seen are to run tasks eagerly, or test the underlying function and avoid test Celery .delay/etc at all

[wormlord]

I just rolled my own mocked Celery objects. I have mocked Groups, Chords, Chains, and Signatures, mocked Celery backend, and mocked dispatch of tasks. Everything runs eagerly because it's all just running locally in the same thread, but the workflow still runs properly-- the output of one task is fed into the next task, the tasks are updated, etc.

I actually pass Celery and the functions like `signature`, `chain`, etc as a tuple into my service layer functions.

It's mostly just to test that the piping of the workflow is set up correctly so I don't find out that my args are swapped later during integration tests.