1

I have been reading (and watching presentations) about subjects like: DDD, TDD, BDD, SOLID (principles), design patterns, clean code, clean architecture, agile project methodologies.

All in all I have quite a clear view on how to approach agile software development. Especially the DDD part really helps in communicating to all involved in the team (stakeholders, product owners, team members, etc).

Developing good software is tough and I really value the opinions of experienced developers. They however say things like: "The user interface (or database) is an implementation detail".

If you are looking from the core value of the product that is certainly true. In reality however, the end user solely deals with the user interface. To make our product really useful we need to have an excellent user experience.

Let's say that we have a single page html/css/javascript client. Designing and creating all of the "only user interface" stuff is quite doable. I run into trouble with the following things:

  • Domain logic - It lives in my domain model on the server. It feels fragile to duplicate it in the client. Exposing those parts of the domain model on the server might be an option, but that would probably create a lot of requests (a performance issue). Yet requiring the user to enter a value between 0 and 42 is clearly a business rule.
  • User stories / Scenarios / Behavior / Use cases - Whatever you call it. The server is able to handle the use cases, if we've done it well they are nicely specified by behavioral specifications. The user interface should implement a 'view' or 'guide' for these scenarios. We should probably reuse these right?

I could not find anything about the combination of these things. Do you have any resources or idea's about this?

There must be some smart person that has said something very enlightening about this subject, otherwise: here's your chance

closed as unclear what you're asking by Robert Harvey, gnat, GlenH7, user40980, amon Jan 25 '14 at 9:25

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Does the software meet the customer's requirements? All this ceremony is for naught if it doesn't. I'm not really clear on what you are asking here. – Robert Harvey Jan 21 '14 at 23:35
  • It's a theoretical question mainly on how to deal with domain logic at the client side. The second point is about using the behavior specifications on both client and server side. – EECOLOR Jan 22 '14 at 21:05
  • OK, I'll attempt an answer. – Robert Harvey Jan 22 '14 at 21:08
  • Sometimes i find that clients can get to a very complex logic and that it's better to treat it like a app of its own with its own DDD domain model and abstractions. For example AngularJS app can be the framework using a bunch of JavaScript domain objects and the repositories implementation just get the data from a REST service, cookies, browser storage etc... – danfromisrael May 14 '15 at 6:51
3

How much domain logic you have in the client-side UI will depend largely on how much interactivity and responsiveness you want in the UI.

For example, let's say you want to validate some field that the user enters. Maybe that validation involves other fields on the form (you asked for socks, but you didn't specify what color of socks you wanted). In most systems with low interactivity, this would involve a round-trip to the server, where the server would validate all of the fields, and then send a new page to the client with the fields that didn't validate highlighted, along with some useful error messages.

On a high-interactivity form, you wouldn't get a postback. Instead, the form would simply tell you "you forgot to specify a color for your socks," and hold off on the postback until you specified a color.

Or maybe you're putting in the Year, Make and Model of a car (what we call "cascading dropdowns"). On most decent web pages, this requires an AJAX trip to the server to update the next dropdown, based on the previous dropdowns. Poorly-designed web pages require a POST and a complete re-rendering of the entire page just to update the next dropdown list.

Well-designed, high-interactivity pages work just like desktop applications. This used to be done with Flash, but now you can do it very well with web applications (See Single-Page Applications for a proof of concept).

Of course, you still need to validate again on the server, since you ultimately can't trust the data that a client sends you, even if the client has validation logic.

Not the answer you're looking for? Browse other questions tagged or ask your own question.