Fork me on GitHub

@jlmr I agree with all the previous comments (,, and the talk linked above on ports-and-adapters). With regard to your comment on deployment, Docker can be very helpful for development as well (because it compartmentalizes your app’s dependencies away from the host system by managing the dependencies within the Docker images). Try hard to use a PaaS (platform-as-a-service) like Elastic Beanstalk, App Engine, or Heroku before reaching for CaaS (containers-as-a-service, like Kubernetes, ECS, etc) — PaaS is a higher level-of-abstraction and has better ease-of-use than CaaS (with the trade-off that you may lose some ability to control lower-level details). Keep in mind that you can deploy Docker images to VMs, if you so desire. For experimentation and learning, check this out (single-node, Heroku-like PaaS focused on ease-of-use): I’d also add these, as further jumping-off points for learning: • (how the pieces of the stack fit together!) • On the DDD front, I’d avoid going down the CQRS/event-sourcing route unless you’re absolutely sure it’s what you need. I find the ideas behind DDD extremely useful (bounded contexts, etc), even for CRUDL applications, and without building everything around events.

Ahmed Hassan18:02:55

Can we use Dokku in production?


In short, I don’t see why not. I haven’t myself. I would read their docs and understand its capabilities and limitations before taking it to prod. It’s best practice to have multiple nodes, to help with high availability. Dokku runs on a single machine. For production, you could perhaps front multiple Dokku nodes with a load balancer (perhaps provided by the cloud platform you host on, if that’s relevant). For the DB, you could use a managed, HA DB from your hosting provider.