Re: Modeling the user registration process

Hi,

Thanks a lot for taking the time to formulate such a detailed reply. Please see my comments below.

1. Actually I've just started reading on the Party and Role Object analysis patterns, so I will need to reconsider this. The supported application isn't all that complicated (service providers, service consumers and administrators) but UserAccount just doesn't feel right - for the moment Person seems more appropriate.

2. Not sure about the *.commons.* stuff either. It contains utility classes that could be part of the domain or infrastructure. ThumbnailProducer could be a domain service interface, but what about its AwtThumbnailProducer implementation? Is it a domain service or an infrastructure service since it relies on AWT? Today I'm leaning towards moving them to the domain.

3. I totally agree with you regarding dependencies to application, and so only UserAccountServiceImpl (application service) uses application.user.verification. Whether email verification is an application or a domain service is very unclear to me - it's part of the domain vocabulary, it involves concepts of the domain, but the domain could well exist without it? Really this boils down to: what distinguishes an application service, a domain service and an infrastructure service?

4. I agree, see #2. Thumbnail production is used elsewhere in the application, and so has been isolated in (Awt)ThumbnailProducer. DelegatingProfilePhotoThumbnailProducer implements domain ProfilePhotoThumbnailProducer and delegates to (Awt)ThumbnailProducer. Lots of interfaces and classes for a very simple requirement.

5. The reason I didn't introduce a ProfilePhoto domain object is that I want to avoid loading the photo's bytes every time I load a UserAccount instance. We're not talking about gigabytes of data, but still. So UserAccount maintains URL references that are used later in order to load the photo bytes. I'll try introducing a ProfilePhoto domain object that wraps the URL reference and see where that leads me.

6. Right.
7. Good idea I'll try this out.

Another question that came to mind was:

8. Is UserAccountRegistrationService really necessary? Right now it's a domain service that builds a UserAccount from a UserAccountRegistrationRequest (using the Builder), marks that UserAccount as registered, stores it through the UserAccountRepository and uses the ProfilePhotoUpdateService to update its profile photo. It's called by UserAccountServiceImpl.registerUserAccount. Originally, this logic was implemented in the application service method, but I figured it somewhat looked like a transaction script. It seems fine, but again it's a long delegation chain: UserAccountRegistrationController => UserAccountServiceImpl => UserAccountRegistrationService => ...

Thanks a bunch.
GB

--- In [email protected], Jörgen Andersson <jorgen.x.andersson@...> wrote:
>
> Hi,
> 
> From the description of your domain I can't see all details. But on the
> overall level I think you have a good design. It is very much like what I
> would do myself. In the links below I have described the approach to
> DDDthat I have been using, first by high-lightning the non-technical
> aspects
> (ubiquitous language and using a structure close to the business) and then
> technical aspects (separation of business and technical concerns, layering
> and technical building blocks).
> http://se-thinking.blogspot.se/2011/10/is-domain-driven-design-always.html
> http://se-thinking.blogspot.se/2012/09/ddd-on-top-of-services-ddd-inside.html
> 
> I hope that can give some additional background to my answers to your
> specific questions:
> 1. UserAccount/User/Person/etc. The choice depends on what is in the
> ubiquitous language. Perhaps you might even find that there are different
> bounded context (e.g. one where the UserAccount is created, and others
> where the User can do things, backed by the BC with the UserAccount for
> authorization).
> 2. I think the packaging looks reasonable. Not sure about the stuff in the
> "commons" package, but otherwise.
> 3. It seems OK. What I can't see from your description is who is depending
> on the services in "application.user.verification". In my view neither
> "domain" nor "infrastructure" should depend on "application". Calls to
> "application" should all come from outside and is, in my view, just a
> special purpose integration layer and should contain no business logic.
> 4. Looks fine to me in terms of dependencies. Might be that the
> DeligatingProfilePhotoRepository doesn't do much and hence could be
> eliminated, but that is something I can't tell from your description.
> 5. Yes, I think there should be a ProfilePhoto (or whatever name is used in
> the ubiquitous language) domain object. I don't like the idea of having
> APIs described in terms of raw byte[], since the domain always imposes some
> restrictions of what can be in it. It is never a byte[] with a random set
> of bytes. In this case it is a byte[] where the bytes together should make
> up a photo. Creating a properly named domain object, starting as a simple
> wrapper on the byte[], makes the code easier to read. And in addition more
> often sooner than later that domain object seems to be a proper place to
> put some functionality.
> 6. Coming back to my answer on no. 3 it might very well be a domain service.
> 7. It seems to contain some business logic, and then it should be a domain
> service. For the integration part I would define an interface for an
> external service in the language of the domain and have a thin integration
> class using the JavaMail API for the heavy lifting.
> 
> Hope my thoughts make sense to you.
> Jörgen
>




------------------------------------