I'm wondering how a rule tailored for a specific UI is handled in a context of DDD and hexagonal/onion architecture?

For example, if you have a screen for an inventory app where you can create product which are displayed as a list. The specifications tell you that newly created item should appear at the top of the list but the user can reorganise item order just for visualisation purpose.

I'm a bit reluctant to store some kind of order property in my product entity because if UX change the domain is impacted.

So I wonder what are my other options to handle theses use cases?

  • Maybe worth to mention that the ordering must bé persisted Somewhere if the user go on other pages and return to this one Apr 16 at 9:37
  • Do you have a backend (beyond just the database)? Note that, if you can have multiple users, they'll reorder the items differently, so you can't put the order inside the domain model entity anyway (cause they'll overwrite each other). Are you going to persist this ordering across sessions (user state retained days later), locally vs server-side (does the user see the same order when accessing from a different machine), etc? You need to figure these things out (al least as a first pass) before you decide on a design. Apr 16 at 12:06
  • Yes multiple user , presentation must be idempotent whatever the laptop his. I'm wondering if i need some supporting domain like user préférence ? But it seems to be overengineer for a this kind of use case. Apr 16 at 13:54
  • You can conceptually think of it as of a supporting subdomain, but its realization/implementation doesn't have to be complicated. Could end up being just another table. These higher-level DDD concepts are not rigid patterns that you always apply a certain way (that way of thinking is pretty much anti-DDD). Think of them as a way to clearly define conceptual boundaries for areas of different responsibilities; this then helps you (and your team, if in a team) keep things straight, and lets you work through how these parts of the application should interact. Apr 16 at 14:31
  • In fact where i'm a bit Lost is who will feed this table ? Is my infrastructure/repository silently attribute a position when a product is created which seems not the right thing to do ? what about when a user update position ? All is handle by a service located in app / infra layer ? Code for this is pretty easy but where to place such code is the hard part. Apr 16 at 14:47


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.