4 ms·
And nothing about business needs and wants, working with stakeholders and all the rest? I’ve seen both newly minted and seasoned “architects” fail again and ag
by willvarfar 6y ago
And nothing about business needs and wants, working with stakeholders and all the rest? I’ve seen both newly minted and seasoned “architects” fail again and again because they think in terms of technology not business.
- theptip 6y agoThe article explicitly covers that one: > 2. Don’t ignore the domain It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering.
- willvarfar 6y ago-shrugs- I don’t get that from that paragraph, but I guess it depends on how one thinks the author means “domain”. I’m used to meeting “domain experts” who know all about the corner cases in the current implementation. Often they are the people who argue with the suits and it never ends well for them.
- mateo411 6y agoThat doesn't sound like a domain expert. This sounds like somebody who is pretty familiar with the current implementation. A domain expert understands the business use case and the market. I would say they can act as a good Product Manager.
- theptip 6y agoIt's specific jargon in the Domain Driven Design community; "domain" == "business domain". Some of the links in that section of the OP give more detail. I recommend DDD in particular, it's a great architectural framework, though it's a bit dense and hard to approach. A good starting point: https://martinfowler.com/bliki/DomainDrivenDesign.html https://martinfowler.com/bliki/DomainDrivenDesign.html