May 2006 - Posts
Peter Veentjer published his second post on Domain-Driven Design in which he questions the need for a Service Layer. First, the Service Layer is what Eric Evans calls the Application Layer. Let’s see what Eric has to say about this particular layer in his excellent book Domain-Driven Design.
Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
According to Peter the Application Layer is still very useful for security, transactions, decoupling and as a facility to store application logic. I’m not sure about the security and transactions in the service layer since it leads to the problem of not isolating the domain. The all seeing eye Frans Bouma responded with:
How can the Application Layer coordinate tasks and delegate work if it doesn’t contain business rules?
Interesting question!
Let’s concentrate on DDD and the patterns that play a role in this discussion: Application Layer, Domain Layer, Infrastructure Layer, Application Service, Domain Service, and Infrastructure Service. With these patterns in mind I tend to agree with Eric that it is straightforward to identity Infrastructure Services, but significantly harder to distinguish Application from Domain services. What I find a big help in separating the apples from the oranges is thinking in terms of application workflow. All logic concerning the application workflow typically end up being Application Services factored into the Application Layer, whereas concepts from the domain that don’t seem to fit as model objects end up forming one or more Domain Services. Otherwise you’ll be definitely messing up a real model object which, in my opinion, has been done in Peter’s example. Human Resource Management fires people, since they are the ones that know the details about the “firing policy”, that is, assuming I am the domain expert in this case. To capture this important domain concept I would introduce the HrmService, Domain Service in the Domain Layer. This way the Application Layer does not contain any domain/business related logic and focuses on the application logic only.
Now let’s see what Jimmy Nilsson has to say about the Application Layer in his more down to earth book Applying Domain-Driven Design and Patterns.
The Application Layer isn’t mandatory; it is only there if it really adds value. Since my Domain Layer is so much richer than before, it’s often not interesting with the Application Layer.
Right on the spot! So, the question remains: when do we need an Application Layer and Application Services? Imagine we need to build an application on top of our Domain Model using the HrmService, Domain Service to accept an employee-firing request from this big SAP system. It requires the HrmService to determine whether it’s possible to fire the given employee by interacting with the necessary Employee, EmployeeFile, ContractFile and FirePolicy objects. We also need to communicate the advice by sending e-mails, letters and other communications for which we use the Infrastructure Layer. We now have captured a small part of the application workflow which fits nicely inside the Application Layer. Now part of the Application Layer’s responsibility is to digest the employee-firing request and send a message to the HrmService, Domain Service for fulfillment. It then decides to send notifications to the Infrastructure Service.
It’s important to note that the domain layer isn’t being distracted from representing the important concepts of the business, a healthy heart I'd say!
Tech Ed 2006, Boston is sold out so Microsoft decided to broadcast sessions live! Check out the Tech Ed 2006 Webcast Series for the available live webcasts.
I finally decided to step away from the Simple - Blue skin. A while ago I received the disturbing news that my blog didn't render correctly in Firefox, but haven't spend any time on fixing this issue since I had the feeling Community Server was on its way to replace the good old .Text blog engine. Another issue with the Simple - Blue skin is the horizontal scaling which makes a blog unreadable on 24-30 inch panels. Trade offs: I really dislike the navigation, now residing on the left side of the page.
The title banner is based on a photo Kitty took from me and Woofer on Cap Blanc-Nez, France near Calais. I have always been fascinated by E. Rommel's Atlantic Wall which is why we visited the Sk. observation bunkers (Schabelstand) while passing through France.
So, I guess I'm all set to go. Big thanks to all who helped with the transition to Community Server!
I just installed Windows Vista beta 2 (build 5384) on my AMD64 3500 running Windows XP and Virtual PC 2004 with 2 GB Ram addressed to it. Sluggish… the unbearable slowness by which Vista runs makes me want to pull my hairs out. After installing the Virtual Machine Additions it runs somewhat faster, but still nowhere near acceptable for actual testing. But hey what to expect from a VM Additions S3 Trio32/64 driver with such fancy graphics. To be honest the UI is very impressive! Tomorrow, I will probably mount an extra disk to create a dual boot and put my 7800GTX to the rescue.
A couple of weeks ago I gave a short preview of the upcoming .NET 2.0 support in Neo. Since then only a select few tried the early bits which resulted in lots of great feedback, thanks! Unfortunately the subversion system at CodeHaus is temporarily offline, which is holding me off from merging my code. This made me decide to make the bits available to a larger public. Download the Neo2005 Preview_net-2.0 distribution. Feedback would be very much appreciated!
For additional information see:
Neo DSL
Neo2005 Preview
Neo nullable types
Neo .NET 2.0 Support
Run Neo on Visual Studio.NET 2005 and .NET 2.0
MTV did a special on the development process of the upcoming game Gears of War for Xbox360. You can watch the episodes at mtvOVERDRIVE in which the Epic team prepares for E3. Seeing them hitting crunch-mode, playing all sorts of games including table football (which we play at least once a day at our own office) and Tim Sweeney telling, passionate about spending 13 or 14 hours a day on average, programming or thinking about programming, makes my heart beat faster. This reminds me of Triumph of The Nerds (1996). Than Cliff Bleszinski (or CliffyB) runs into Bill Gates…
Bill: How does it look for shipping this fall?
Cliff: We’ll make it happen…
Bill: Fantastic, we’re counting on you!
Priceless!
Arjen quoted Haralampos Routis’s reply over at the Spring Web Services Forum stating: The implementation of the interface is important but it can also change in time. The interface on the other hand cannot/should not change. Thus invest on XML Schema and WSDL, because these are the essence of Web services.
To me an interface implies a couple of things, namely, a service contract and data/message contract and their implementation details, with them, not necessarily having the same versioning strategy.
Service contracts, data/message contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data/message contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data/message contract (XML), but I also want to stress the importance of the versioning strategy.
Roy blogs about his decks and demos available for download at the Tech Ed Israel 2006 site. If you are like me and can’t stand sitting and waiting for Tech Ed Europe 2006 to start, you’ll just have to download the Israel content right here. Since most of the content is in English anyway.
Finally, Applying Domain-Driven Design and Patterns [ADDDP] is on its way to the bookshops. I hope to get a copy before the 10th of June, since I’ll be on my way to Sardinia, Italy as of that day.
In Java the Domain Model pattern is the de facto standard for organizing domain logic whereas .NET still struggles with legacy in which it was very hard to execute this particular pattern. On top of that it has been made far too easy to work with in-memory tabular data. This led to the Table Module pattern being the dominant standard in our field. Martin Fowler introduced me to my current thinking that “logic” rarely fits any logical pattern which leads to the real benefit of objects. In his excellent book Pattern of Enterprise Application Architecture [PoEAA] he described the technical options for developing a good infrastructure. At that time Microsoft supplied guidance in the Designing Data Tier Components and Passing Data Through Tiers paper. Around that time Eric Evans collected his knowledge in the masterpiece Domain Driven Design, Tackling Complexity in the Heart of Software (DDD). I remember the debate and confusion on various blogs regarding entity vs. domain, which Frans put to a stop.
And today? I think there is still a lot of work to do (with .NET in mind). Microsoft is finally lending a hand in the sense of framework and tool support. Models are gaining interest in new technology stacks (MDA, DSL)… and finally we have a developer focused title to clamp on to while we bridge the gaps between PoEAA and DDD in code.
Hans Verbeeck mentioned the developer track owners and their blogs. Start the dialog with these guys and tell them your thoughts to make this event even better.
Beat Schwegler (architecture, connected systems)
Chad Hower (base framework)
David Boschmans (web development track)
Gerd De Bruycker (overall owner event)
Gunther Beersaerts (SQL Server)
Mario Szpuszta (2007 Office System)
Niels Hilmar Madsen (tools and languages)
More Posts
Next page »