A very common practice in our industry is to first build the UI and tie in the back-end thereafter. The argument, for the most part, has been that the end-user gets more involved from the start with this approach and thus it gives us confidence that we are indeed building the right product. One major downfall I've realized with this approach is that we tend to end-up with a poor domain layer or lack of it for that matter. Since we are so focused on feeding data into our shiny UI. Here is a quick example to illustrate my point. Decouple the UI and the data layer from your application and see how much can be reasoned about with what's left. In other words, when all the bells and whistles are stripped off, what do you have left? How rich is your domain or what's your domain for that matter? What is your application about and how apparent is that in your code?
Ok, so maybe you can make a point that there is such a thing as a two-layered application and that not everything needs to be domain driven. Point taken. The most compelling reason I've seen for thriving toward a rich domain is that it's easy to test and reason about your application. I find it extremely helpful to think of my application as serving use cases rather than serving data. Huge difference. And what a better place to exercise your use cases than through a rich domain.
So what's a rich domain? I think of it as a layer that speaks my business domain and expresses allowed use cases. How rich it is, depends on how versed it is. Therefore, next time you find yourself designing user interfaces prior to expressing use cases to be served, my suggestion is to start from the latter and walk your way up. Let your UI plug into your domain.
Top comments (6)
I'm totally with you on building domain use cases first.
I'd take it a step further and try to remove the technical from it. Then the order doesn't matter and can potentially be worked on in parallel.
The use cases need a user first which in most cases is a human, so it's equally important to design your UI use cases also. Software is built for humans first.
Agreed. Use cases is a bit of a loaded word so perhaps a bad choice.
My intent was that shared understanding of the goals based on user needs would need to be established before starting the formal UI or the backend. Starting without will likely be a difficult road regardless.
The Formal UI and backend knowledge would leverage mockups and wireframes that were made during the quest for shared understanding. Keeping in mind it'll likely change as the process moves forward. ;)
The fastest way I've found is to create a data and domain model while working the UI in a wireframe tool. Review wireframe with users until they see what they expect and both UI and wireframe with developers until they understand the domain. Document and use as a guide, not the absolute truth or spec as many things will change. Then break the project into smaller pieces, prioritize, and build using agile.
How do you define the limits, abstractions of the domain if you don't know what the user will want/use?
Good question. I would say that those abstractions are defined by the business rules. These rules should not know about the existence of the presentation layer nor should the presentation layer be concerned about where the data comes from.