Undesirable side-effects with a lack of a domain model

    If we fail to recognize when we need a domain model, we'll run into problems like:

    • Missing abstractions and fostering a breeding ground of duplicate code
    • Writing untestable and tightly-coupled classes
    • Using computer-y sounding class names like 'handlers', 'factories', 'managers', 'interactors', making comprehension a real challenge for anyone else other than the original author
    • Not caring about the actual problem domain and writing code that doesn't…
    Let's resend your copy of the 📕
    Enter your email that you used to purchase it with.

    Howdy 👋

    This is an online wiki and book about the basics of software design and architecture with TypeScript by Khalil Stemmler, Developer Advocate @ Apollo GraphQL .

    This book’s mission is to teach developers the essential skills and practices to write testable, flexible, and maintainable code.

    You can read more about the learning journey in the "Software Design and Architecture Roadmap 🖼️".

    Already bought it?

    If you’ve already purchased the book, click here to re-send your link. You can read the online wiki or download a copy of the book in PDF, EPUB, and Kindle versions.

    Want access?

    You can read the intro to the book for free and visit solidbook.io to buy the book/wiki (it's currently on pre-sale for 33% off)! For recent updates, click here. To get an idea of my writing, read some of my best free content here and here.

    Need help?

    Something not working? Have a question? You can reach me on Twitter or khalil@khalilstemmler.com.