DDD-Software Design, A Two Person Job

In my previous blog, I described what happened when Domain-Driven Design met Deadline Driven Design. Software design is a complicated activity. Pushing the deadline doesn’t work in most cases; cutting the software design will never work.

Not existing no-design-software, it’s either Good or Bad

Let’s first explain “the two-person job” mentioned in my previous blog. A basic question first.

Who designed your software?

A, UX designer; B, Architect; C, BA; D, Developer;

If you choose A, I would point your attention to Steve Jobs’ Quotes

“Design is not just what it looks like and feels like. Design is how it works.”

If you choose B, I would argue that building software is not like constructing a building. It’s much more complex, you can’t copy and paste. Constructing a building usually can be broken down into well-defined duplication work. However when software is broken down into user stories or tasks, they are very different and require expertise. Besides, some development teams don’t have an architect role at all.

What happens when BA designs the software?

What I found in my personal experiences is that when BA is keen on giving suggestions or estimations in technical details, their contribution to software design and implementation quickly become chaotic or are treated as a conspiracy. They either overlook…