3 ms·

As much as possible, build horizontal, functionality based services. As much as possible, avoid coding anything business specific into your core. Avoid product

As much as possible, build horizontal, functionality based services. As much as possible, avoid coding anything business specific into your core. Avoid product names, role names, user types, etc, in your code, databases, classes, files, APIs, services, etc. Create systems where those things can be entered as data, so configuration can be provisioned and updated by end users. Push the "domain" as far into user-land as you can (users entering data and configuration). Imagine how bad and inflexible bug tracker software would be if there were "product manager" and "software engineer" domains and services. Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain. That's why he argues Excel is so successful, there is no core domain nonsense, it's a functional piece of software that users can use to create whatever domain they want. As much as possible, avoid Domain Driven Design, except for the minimal useful parts (like using the same name for things in the same context).

pragmatic 4y ago
There’s a downside to this as well though. You end up trying to debug/understand logic that slips through your hands like wisps of smoke. It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.
rvdginste 4y ago
I don't believe in this: if you follow through on that, you will end up with a low-code or no-code platform. Or basically, you are creating a programmable platform where your "configuration" is actually gonna be code. When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes. Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to. If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad. And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code. > Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain. I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution. Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.

pragmatic 4y ago

There’s a downside to this as well though. You end up trying to debug/understand logic that slips through your hands like wisps of smoke. It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.

rvdginste 4y ago

I don't believe in this: if you follow through on that, you will end up with a low-code or no-code platform. Or basically, you are creating a programmable platform where your "configuration" is actually gonna be code. When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes. Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to. If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad. And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code. > Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain. I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution. Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.