18 ms·
I think this is an artifact of domain driven design taken too far. Perhaps it works well in organisations like Netflix, Spotify, etc but I would tread very care
by stingraycharles 9y ago
I think this is an artifact of domain driven design taken too far. Perhaps it works well in organisations like Netflix, Spotify, etc but I would tread very carefully with this indeed in an organisation with less engineers.
I always find that these domain boundaries in which teams operate are “leaky”, and result to noticable inconsistencies between them to the end-user. If you can’t afford the overhead of making sure that these inconsistencies are caught and fixed, don’t do this.
- bsder 9y agoIt's an artifact of two dimensions, one good and one questionable. The good dimension would be hard security bounds. Lots of people are starting to look very strongly at security in depth and realizing that they need hard boundaries between tasks or security isn't even possible. The questionable dimension is political. If I can force something into a "microservice", I can extend a political control boundary around it. Now, if something feeding me or consuming me screws up, I can say "Not my fault. Yell at him." This is probably more useful in larger companies than startups.
- glenjamin 9y agoBoth this and microservices are primarily tools to attempt to make it possible to scale software teams to large numbers of people. If you don't have a need to scale to large numbers of people, you almost certainly shouldn't attempt to apply these techniques.
- DigitalJack 9y agoI feel like there is another aspect that is helpful. It's another way to partition an application into surmountable "bite size" chunks. There are plenty of other ways to do this, but if this is what helps you think about the problem, go for it.