I personally don’t recall anyone advocating tons of tiny (a few 100 LOC) services before, one for each single feature.
7
1
3
@stilkov I’m honestly still trying to figure that out.
1
@kellabyte @stilkov @boicy We didn't find few 100 LOC a general characteristic. Our thoughts on size (so far) martinfowler.com/articles/mi…
1
3
@martinfowler @stilkov @boicy Yeah. I think the “micro” is just going a little wild in some other people’s posts.
1
2
@kellabyte @martinfowler @stilkov @boicy That’s why I prefer Replaceable Component Architecture. “Micro-“ suggests smaller-is-better.
4
4
7
@tastapod @kellabyte @martinfowler @stilkov I think micro as antonym to macro - as far as I know monolith has no antonym unfortunately
1
@boicy @tastapod @kellabyte @martinfowler As tempting as it is to lose the literal “micro” meaning, it becomes a lot less distinctive then
1
@stilkov @boicy @tastapod @martinfowler I’m still trying to figure out what is distinct period. Maybe I’ll accept the name once I see a diff
5
Replying to @kellabyte
@kellabyte In the SOA approach I advocated, a service was a mid-sized, autonomous unit, with maybe a few dozen classes, e.g. OrderManagement

Mar 16, 2014 · 6:22 PM UTC
1