I think this is the rough sketch that I wanted the architect to do back at my old job. But now, as I've been diving deeper into this stuff myself (I'll admit, there was just no motivation to improve anything back there), I've drawn this for my teammates here on my cubicle's white board.
It's a basic diagram of the domain layout I'm working towards here, and if you were at my last job then you may notice it borrows heavily from that design. I've changed a good bit in the interaction between the handlers and the processors to accommodate the different application ecosystem at my new job, but there wasn't enough room on this little board to go into much detail there.
One thing that may help in pushing this idea at my current employer (being a financial institution) is the auditing at the single entry point. If the client applications are as dumb as possible and all of the business logic is in the Processors and all of the actual data persistence/interaction is in the Repositories, then having that single entry point is a convenient place to keep a detailed audit trail of all requests that come in to the domain.
Wow great diagram. I would ask are you working towards the anemic domain model that we had when we worked together or working towards more of a fuller domain model?
ReplyDeleteA link of interest perhaps:
http://en.wikipedia.org/wiki/Anemic_Domain_Model
I've been leaning towards the Anemic model for a few reasons:
ReplyDelete1) It allows all levels of the code to share the same domain objects, which represent concrete business concepts, without muddying the waters with the logic for those objects. For example, if someone puts a function on the User object that interacts with some other domain logic in some way, it could be very unintuitive for another developer working with a User object outside of the service boundary to know if that function will work or not.
2) Service-based, functional programming seems easier for everyone to grok (myself included), and a primary goal here is to make code easier to develop/support for the business as a whole.
3) Functional programming got a bad rap for a long time, and I'm glad to see it getting more attention these days :)
4) If objects are "dumb" then I see them as being more state-driven. An object gets passed around from code to code, changing state a little bit each time. Logging/auditing can easily be performed between these state changes.
I think I need to re-draw the diagram on a surface with more vertical room. I want the domain sphere and the repository implementations to look more like the Phantasm ball. Maybe on fire.
ReplyDeletePlus, multiple representations from multiple points of view (how the actual Visual Studio projects are organized, for example) would make for better overall documentation.
I'm still back and forth on the anemic model. I don't think that doing an anemic model means you are doing functional programming but it certainly means you are doing a more procedural style. Of course we are in an object-oriented language and using an object-oriented framework. Then you have to deal with a communications barrier sometimes and you can't send sophisticated domain model across. Perhaps that's an argument for two models, I don't know. Having a single anemic model that the whole application shares means you have everything depend on it (even presentation and services)....
ReplyDeleteI should try and compile my thoughts about this topic.
It's by no means a golden hammer, that's for certain. Nothing is.
ReplyDeleteDefinitely compile your thoughts on it, the main purpose for this blog is to exchange ideas and share/learn stuff. I'd definitely be interested in seeing any designs you have in order to broaden my own understanding.
This comment has been removed by the author.
ReplyDeleteI'll try to work on it in the coming week. Like I said I'm still back and forth on the anemic model. It seems like the richer domain model is very useful in the middle tier where you have to worry more about the relationships between objects and business rules around those relationships, but then having to go between layers what do you do?
ReplyDeleteI'm currently playing around with some admin interfaces and I'm doing it with some javascript fanciness (although I'm probably about to drop it all and do more straight up webforms as much as it pains me). I'm right now staring at the fact that I have a complex object that has relationships to other objects that is easy to work with but could lead to trouble if I serialized it. Now just doing the databinding and rendering the page server side is no big deal (we are in a 2 tier project), but if I want to serialize it out to the client for all the rich interactions that javascript provides I run into the problem of having to introduce a mapping between the rich object model (domain model) and a simplier one (DTOs). I'm trying to decide what's worth it and what's not.
This is getting interesting. One of the things my current shop doesn't seem to like is the idea of "one service to rule them all." They see it as a single point of failure and don't want to group together critical applications with relatively unimportant applications, trying to mitigate the risk of the latter breaking the former.
ReplyDeleteSo I'm currently tinkering with a design that involves multiple domain cores served by multiple services. It definitely challenges the plug-and-play nature of the repositories, but so far that's going rather well.
At the very least, this is going to require a little more client-side configuration from me. Consuming multiple Agatha services doesn't seem to be a problem, but I want to abstract it as much as I can from the developers so they don't have to worry about it.
We'll see how this goes...