Some thoughts on architectural refactorings

[alastairs]

Since attending Ian's NxtGen talk on SOA and EDA, I've had a couple of thoughts about how we could re-do the site to follow SOA principles, and thus improve the site along the lines of:

• performance/high availability
• "generifying" it for other DDD events

This is a summary of where I've got to so far. I'm not saying it's complete or even right, but hopefully it's a jumping-off point for some discussion.

• One service per "milestone" in the pre-event time-line: i.e. services for submission, voting, agenda, and registration.
• One service for conferences themselves. Probably this would be little more than a source of identity for a conference that could then be passed to the other services.
• Perhaps a small set of services for users (e.g. registration and account details). This is more going down the fine-grained SOA model that Netflix uses, and may not be appropriate for us.
• Particularly for registration, we could better handle registration ourselves by scaling out (i.e. multiple instances of) the registration service. Handling over-subscription could be tricky in this environment, though.
• Azure Service Bus or some other MOM would make for good communications "glue" between services.
• This would also allow us to turn features on and off at the appropriate times by spinning up and down Azure resources. We could keep some information in the website itself so we could spin down all the back-end services outside of conference season.

The downsides to this approach are greater complexity in architecture and deployment, but it is by no means insurmountable complexity. For example, deployment of services to Azure is actually a solved problem and easy to read about and thus not too hard to implement.

[philpursglove]

MOMA?

----- Original Message ----- From: "Alastair Smith" notifications@github.com To: "dddeastanglia/DDDEastAnglia" DDDEastAnglia@noreply.github.com Sent: Friday, 3 May, 2013 3:28:26 PM Subject: [DDDEastAnglia] Some thoughts on architectural refactorings (#158)

Since attending Ian's NxtGen talk on SOA and EDA, I've had a couple of thoughts about how we could re-do the site to follow SOA principles, and thus improve the site along the lines of:

* performance/high availability 
* "generifying" it for other DDD events 

This is a summary of where I've got to so far. I'm not saying it's complete or even right, but hopefully it's a jumping-off point for some discussion.

* One service per "milestone" in the pre-event time-line: i.e. services for submission, voting, agenda, and registration. 
* One service for conferences themselves. Probably this would be little more than a source of identity for a conference that could then be passed to the other services. 
* Perhaps a small set of services for users (e.g. registration and account details). This is more going down the fine-grained SOA model that Netflix uses, and may not be appropriate for us. 
* Particularly for registration, we could better handle registration ourselves by scaling out (i.e. multiple instances of) the registration service. Handling over-subscription could be tricky in this environment, though. 
* Azure Service Bus or some other MOMA would make for good communications "glue" between services. 
* This would also allow us to turn features on and off at the appropriate times by spinning up and down Azure resources. We could keep some information in the website itself so we could spin down all the back-end services outside of conference season. 

The downsides to this approach are greater complexity in architecture and deployment, but it is by no means insurmountable complexity. For example, deployment of services to Azure is actually a solved problem and easy to read about and thus not too hard to implement.

— Reply to this email directly or view it on GitHub .

[alastairs]

Slight typo, should be MOM - Message-Oriented Middleware. Have updated.

(MOMA is the Museum of Modern Art :smile:)

[ninjaferret]

I was thinking the same after the NxtGen talk.

Completely agree about breaking us up into the fairly unrelated concepts that are present on the conference.

• Conference
• Calendar - so that public (and private) milestones can be recorded here, with the ability to generate e-mail/other notifications
• Session Proposal
• Voting
• Agenda
• Registration
• User
• Venue - too granular?
• Sponsors - too granular? Perhaps this could stay with the conference

You are right that this increases architectural complexity but simplifies changes within a single conceptual boundary. In terms of deployment, if we make the services backwards compatible we can deploy the service first and the consumers of the change can come in a later deploy.

I would prefer we weren't "date-driven" on most of the actual services, would much prefer us to me "message driven", e.g. to open voting the Calendar Service (or something else) can send the "OpenVoting" command - so potentially the calendar service could either

• Send a message itself to the services (probably running a azure service)
• Schedules the messages/manages the messages on Azure Service Bus

This would (make testing easier) but mean that they don't really care about dates inside those services and they can focus specifically on their task.

Initially, each service could still run on the same Website instance, farming out the more expensive ones like registration to a separate service when we know there is a need for it.

I would also look at hosting more of our static content, like sponsor logos etc on a CDN rather than serving them from our own instance.

[alastairs]

Per our Skype discussion this evening, we could use the EventBrite API to handle future registrations. How would our site handle the load from registration, though? Would we need to think about using a message queue between us and EventBrite? Not sure how those bits fit together yet.

[alastairs]

Some thoughts on a domain model for the website:

Entities:

• Conference - to allow for a multi-year/multi-event site
• Person - a registered, authenticated, user of the website.
• Submitter - A Person who submits a talk proposal.
• Speaker - A Person who delivers a Session on one or more Topics.
• Session - an item of content on one or more Topics, delivered by a Speaker
• Agenda - a collection of Tracks, specific to a Conference
• Track - a collection of Sessions, possibly on a common theme, where each Session is fitted to a particular Time Slot.
• Time Slot - within a Track, the start and finish time for a Session.
  • A Session can be assigned to a Time Slot in a Track, and the resulting combination of all Time Slots across all Tracks is the Agenda.

Entities should be mutable, through well-defined behaviours exposed on the class (not through Property setters). It might be that mutating state means creating a new type of Entity from the current one, e.g. promoting or selecting a Submitter to become a Speaker.

Value Objects:

• Dates
• Times
• Vote - cast by a Person for a Session
  • I'm not sure about this one. I originally had it as an Entity, but the example of Address (included below) made me re-think. Perhaps a Vote only makes sense as a composition of a Person and a Session, in which case it would be a Value Object; but perhaps the uniqueness of the combination of a Person and a Session makes it an Entity.

Value Objects should be completely immutable.

(For clarity: an Entity has identity and as such is unique within the system, and equality between Entities is determined by equality of its identity. Value Objects have no identity, and are represented by their attributes/properties only. Example Entities are: Customer, Product, Container, and Vehicle. Example Value Objects are: Money, Address, ProductCode. Reference: http://devlicio.us/blogs/casey/archive/2009/02/13/ddd-entities-and-value-objects.aspx)