Re: Modeling the user registration process

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