Our great sponsors
-
cookies.js
🍫 Tastier cookies, local, session, and db storage in a tiny package. Includes subscribe() events for changes.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
What he probably means ( he doesn't go into details), is that you can create a simple monolith without splitting up everything.
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore ) with vertical slices and feature folders.
Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat".
The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.
Examples of libraries I've written mostly this way:
- https://github.com/franciscop/brownies
- https://github.com/franciscop/files
- https://github.com/franciscop/backblaze