Allen Helton

Prescriptive guidance on DDD is difficult because it's based on your business domain. What's more, it's based on your specific implementation of the business domain. This is your opportunity to build differentiating software, how you define and treat the domains. In the context of DDD a domain is a responsibility. Usually it's a single component in a larger system. If we use the classic shopping application example, a cart might be a domain. Within a cart you could have inventory items and coupon codes, which are subdomains. This part is up to you and generally shouldn't be decided solely by developers. You need people who know the ins and outs of the business problem to help you decide.

It's important to also track what you consider to be a "scaling event". This will vary based on the use case, but it is important to know when and how long these happen. You can use this to track the difference between a steady increase in traffic over time vs a burst vs some other anomaly. If you're tracking scaling metrics because you handle infrastructure scaling yourself, this is a must have.

People are visual. Abstract concepts become immediately clearer when presented with a visual. Building software visually helps designers and programmers get through iterations I credibly quickly. Tools like OutSystems and Bubble simplify building down to the basics - in a good way. Embrace the opinionated nature of these platforms and you will build software faster than ever before.

A big misunderstanding I see I'm serverless is the assumption that people think there literally "are no servers." Serverless refers to a set of capabilities made available by a service provider. As a consumer you can have your application elastically scale without compromising speed, automatically be tuned with best practices and security in mind, and not have to worry about downtime...ever. Serverless allows builders to do what they love most - build fast. By abstracting away complex networking and configuration setups, you can go from POC to production in record time. Use sites like serverlessland.com, readysetcloud.io, or serverlessdna.com to get quick starts and tips on how to build with serverless services.

This one is hard. Many people think they can do it better themselves. That's not always true. Getting feedback on something you've built is hard both from an "it's scary to ask" perspective, but also from a "accepting constructive criticism" standpoint. Don't take it personal, we all want to see the best software possible. Diversity of thought is how we rapidly scale innovation

Don't underestimate the value you can get from someone who has "done it before". When you get access to individuals, don't be afraid to ask them specific questions. Most people genuinely want to help you and are willing to share tips, tricks, and gotchas. Blog posts and videos are incredibly valuable, but if you ever get the opportunity to talk to someone one on one - do it. Even if they aren't in the same domain as you, computer science problems are all the same (mostly).