Pregunta

There is a domain whose purpose is a reconciliation process between a pretty large number of companies. The process communicates via request and notification messages, each transferred via webservice (SOAP) requests. Each company has to provide an own SOAP endpoint in order to receive request messages and they must send notifications in the role of a webservice client.

The specs at hand describe the process and there are XSD and WSDL files describing the interface.

My preferred approach to design a participating implementation was to look at the domain, work out an ubiquitous language (based on the specs) and create a domain model. I'd like to implement the domain as agnostic in respect of infrastructure/technology as possible, read: while targetting Java EE, JPA I'd like to keep infrastructure dependencies/libraries out of the core domain's code.

When I apply this approach I can achieve a domain model that's pretty good aligned to the language of the specs. At the current point I'm even convinced that it is really expressive regarding details that are quite blurry in the specs. However it's a fact that the domain model differs quite a bit from the webservice model described by XSDs.

Please note: It's very likely that the future users and operators of the system (assumed to be domain experts and scattered throughout all the participating companies out there) will have debates oriented towards the requests and messages on the SOAP interfaces. So there will be the constant requirement for translation between these two models, e.g when a user of my system talks to a developer, when someone does look at the database directly, ...

A second feasible approach could be to force an hard alignment between webservice, domain model and persistence. One could use HyperJAXB3 to map classes generated from the XSD to the persistence layer. Due to the fact that I used @Embedded in my hand-crafted model where appropriate and I simplified and unified some model elements there's quite a difference in the number of resulting database tables, about factor 5. This makes the XSD-based DB schema harder to grasp.

So my "simple" question is: should I strive for an alignment between webservice, domain model and persistence in this domain because the communication is at the very heart or should I continue with my (preferred) solution of hand-crafting a more expressive domain model?

References are welcome.

¿Fue útil?

Solución

One of the most relevant thing to evaluate during the decision process about using or not DDD, is domain model complexity.

If it is "enough" complex and it needs to be maintained over the time, then DDD can be an option.

Similarities of your domain model with concepts (requests, notifications, messages, ecc.) already modeled by existing frameworks are not relevant, in my opinion: they only give you the possibility to build up your solution simply and faster, if you decide not to use DDD.

I suggest you to read also this

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top