Why Domain Driven Design?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • pytest-archon

    Rule your architecture like a real developer

  • Funny coincidence: just one week ago I and a colleague of mine started with "pytest-arch" [1], a pytest plugin to test for architectural constraints. On purpose we kept it very simple. It is already usable and works well, at least for our use cases.

    You can use it to check e.g. if your domain model is importing stuff that it should not import.

    We are planning to publish it soon on pypi.

    [1]: https://github.com/jwbargsten/pytest-arch

  • django-rest-framework

    Web APIs for Django. 🎸

  • > Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).

    Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a different network address to be a different service (think of mounting different apps or microservices behind different URLs, for example).

    Also, I wouldn't say Django is CQRS--CQRS is more or less a different phrasing of "JSON-RPC", which "REST" has become.

    > Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):

    Eh, some people are highly allergic to any boilerplate, but like, the DRF example [0] has practically none.

    That Elm video is interesting, but I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". There's just a lot of inherent complexity there, and my evidence is every mainstream ORM, plus all the "backend-as-a-service" products that are multi-1000s LOC. Then again I think SQL is a great (legendary, honestly) language and we should stop trying to replace it.

    [0]: https://www.django-rest-framework.org/#example

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts