Business Natural Languages Development in Ruby
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Tracking change and innovation in the enterprise software development community
Posted by Rod Johnson on May 31, 2007 01:43 PM
Introducing the SpringSource Application Platform
SpringSource Launches New Application Server without Java EE
Info 2.0: IBM's vision for the world of Web 2.0 and enterprise mashups (Webcast)
Scale your applications without punishing your database
RESTful todo list sample tutorial with Groovy & Project Zero
Nice one again, injecting domain model classes leads to circular dependencies between service layer and domain layer in my opinion. Consider following packages foo.bar.pethealth.domain foo.bar.pethealth.service foo.bar.pethealth.service.impl domain contains all domain classes as Vet, Pet a.s.o., service contains interfaces exposed to clients and service.impl contains the actual implementations. So I am forced not to have a domain object in the IdentityTagRegistrationService interface to not create a circular dependency. Okay, this question lead to the question if its reasonable to expose domain objects to service clients, but for some applications it would be overhead to create DTOs for that purpose 'cause you simply would copy most properties and getters and setters from the domain object to the DTO class and thus duplicate code and create (unnecessary) complexity. All the DTO would be quite anemic, too. Perhaps in the next lower layer the problem becomes more obvious. What if I need to save objects in the logic, or retrieve further objects? DAO interfaces obviously have to expose domain objects. If I had a dependency to the DAO in the domain object then, the circle s perfect. Any thoughts on that? Regards Ollie
Oliver,
domain contains all domain classes as Vet, Pet a.s.o., service contains interfaces exposed to clients and service.impl contains the actual implementations. So I am forced not to have a domain object in the IdentityTagRegistrationService interface to not create a circular dependency.
If we recognize IdentityTagRegistrationService as a "Service" in the DDD sense, it is also a domain element so no circular dependency occurs. (Quite confusing, but Service in DDD is not the same as services of Martin Fowler's Service Layer.) Anyway, I agree that IdentityTagRegistrationService is not a good name for explaining architecture of the sample app.
Perhaps in the next lower layer the problem becomes more obvious. What if I need to save objects in the logic, or retrieve further objects? DAO interfaces obviously have to expose domain objects. If I had a dependency to the DAO in the domain object then, the circle s perfect.
Again, if you include DAO interfaces into domain packages and separate them from DAO implementations in dao package, circular dependencies disappear. This technique is Separated Interface pattern. In this case, DAO interfaces can be regarded as "Repository" of DDD and repositories are residents of domain model in their own rights.
SATO, Tadayosi
http://www.ouobpo.org
That was a good presentation, and indeed how much better does the Java landscape look today. I do hope that Rod and friends someday will take up the defense for OOP in web applications (additionaly with AOP if you want). Clear responsibilies. Encapsulation. All that good stuff should have a place in the web tier like it has in the rest of your software.
Check out this link: http://www.eia.doe.gov/pub/oil_gas/petroleum/feature_articles/2004/worldoilsupply/oilsupply04.html Looks like we've only 40 years worth of oil left. What do we do when we run out?
This was an excellent presentation, that I hope many many people will watch. I wholeheartedly agree with the background description and problem summary, and with the ideas of moving more towards an object-oriented domain model. We have been using this approach in SiteVision for a long time, with AOP as the enabling technology, and have found it to be a good way to avoid the pitfalls Rod outlines. That being said, I think there are better ways to solve this than to use AOP. But, one step at a time. First everyone must understand the absolutely horriffic situation we are in today, as described in the presentation.
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Adoption and interest for Distributed Version Control Systems is constantly rising. We will introduce the concept of DVCS and have a look at 3 actors in the area: git, Mercurial and Bazaar.
Deborah Hartmann interviewed Segundo Velasquez about his experience as customer with an Agile team during the initial phase of software design of a product.
David Cooksey shows how to fine grained versioning to a ClickOnce deployment using an HttpHandler written with ASP.NET, making partial rollouts to a test audience much easier.
Windows workflow (WF) is an excellent framework for implementing business processes, but lacks support for human activities. This article describes a completely generic approach for changing this.
In this interview taken during OOPSLA 2007, Markus Voelter talks about the importance of documenting the software architecture, and gives some good and also bad examples on how it could be done.
William Soo and Meeraj Kunnumpurath discuss the Voca transaction processing system, architectural challenges and requirements, Voca's Spring/J2EE architecture, and the future SEPA architecture.
Security is about trade-offs. Only a few have the expertise to design good security. This talk focuses on Security Patterns, such as Role-based Access Control, Single Access Point, and Front Door.
5 comments
Reply