What's next?

[kareemcoding]

Hey 👋🏽

Thanks for building this! But now that this project has been marked as unmaintained, what's the next best resource for building Domain Driven API's in Django?

[phalt]

I built this with a few goals in mind, and I was lucky enough to be actively working on projects that used the guidelines. Because of this, I got "free" feedback to improve the guidelines as we used them and found bugs or design decisions that didn't work for the project.

So the reason I've set this to unmaintained is not because it's invalid or irrelevant - I just don't actively use it anymore and I feel like that means I won't be able to improve it any more.

Besides, the last merge change was nearly a whole year ago, so I don't think it's going to change much now. If it does change, it'll probably be drastically, and with that, might not even be suitable under the same name.

Keep using it, but be aware that a whole section of the documentation tells you to use what works, and discard what doesn't work, for you.

I do know people are using it a lot, and I really like seeing discussions like this: https://www.reddit.com/r/django/comments/f140f8/django_and_ddd/

That said, I do wish the people with negative opinions let me know directly so I can improve my own knowledge and improve this documentation.

[phalt]

Here's a suggestion, let me know what you think:

• I'll remove the "unmaintained" warnings because they sound like the project is no longer usable.
• I'd like to solicit some feedback from people actively using it to see how we can improve the documentation.
• I'd like to get some PRs up from contributors with those suggested changes.

[kareemcoding]

Hey, @phalt yes I agree to remove the unmaintained warning as it did make me initially think that I shouldn't use this style guide because it's "unmaintained" - I'd instead opt for terminology like "this project is now stable and unlikely to change drastically in the near future".

[klowe0100]

Hi. Just wanted to also send some kudos out to @phalt for writing this up. I've been trying this out with a few of my new Django projects. Thanks for your thoughtfulness and work. I look forward to providing any helpful feedback possible. I'm also really interested in the eventsourcing library (https://eventsourcing.readthedocs.io/en/v9.0.3/) and CosmicPython (https://www.cosmicpython.com/book/preface.html). I would like to try to blend the patterns together. Has anyone reading this tried something like that already and has learnings to share?

[klowe0100]

@phalt I've been using your style-guide quite successfully on a small personal project. Doing so has definitely helped me solidify my mental model of DDD concepts, which is extremely valuable. I'd be keen on discussing the shortcomings you encountered that caused you to abandon this approach. Perhaps the discussion can drive a renewed attempt at a DDD+Django standard. Appreciate any thoughts you care to share. Thanks in advance!

[phalt]

I've been absent for ages dealing with being a new parent, so it is nice to come back to praise. Thank you so much! It is not perfect, but if it works for you then that is great.

[klowe0100]

Congrats on parenthood! That's great!

[flyingdev]

This is great guideline. I have one concern regarding to apis.py role. When we build RESTful apis, the apis will be placed inside apis.py. In that case, from the other domain interface, it won't reference apis.py as it returns http request. Could you elaborate more about this case? Thank you

[phalt]

@flyingdev in your case, you'd be using the interfaces.py in your own domain as an abstraction over the services.py of the other domain. That is the boundary of separation in this instance, not an HTTP API but an interface layer. Does that make sense?