Architecture Rules Enforcement using Aspects
Even though many companies have some kind of application architecture standards, they don't usually have a mechanism to enforce those standards. As a result of this lack of architecture governance, the Implementation (Code) often doesn't match the Requirements (Reference Architecture). Enforcing Reference Architecture guidelines promotes consistency and modularity in the System. It also helps in detecting structural complexity and preventing it earlier in the software development process. As a result, the application code is modifiable, portable, and testable.
In this presentation, I will talk about the significance of enforcing the architecture rules and standards and how to actually enforce them in software development projects. I will start off the discussion explaining various types of architecture rules that range from simple module dependencies to enforcing how APIs and specific idioms should be used. All these rules usually fall into categories such as Layered Architecture, Separation Of Concerns, Domain Driven Design, and Infrastructure. Some of the rules examples will include basic validations like DAO (Persistence) layer shouldn't depend on any other layers, Presentation layer should not use DAO classes directly, and Service layer should never call web layer. Separation of concerns rules are no transaction management in DAO classes and Service layer should be transactional. More sophisticated rules like that are used in a Domain Driven Design project such as Service object creation through a Factory object (i.e. no Service instantiation using the new keyword), No direct access to DAO's except from the Domain classes (go through Domain or Repository objects), and Business service that fails with a concurrency related failure can be retried.
The presentation will also include the discussion on Static and Dynamic Analysis architecture enforcement setup types and the techniques and tools architects can use for the enforcing the rules. Some of these techniques include Aspect-Oriented Programming (AOP), AspectJ Design Level Assertions (DLA's) and Design by Contract (DbC). As for the tools, Macker can be used for identifying module (package) dependency violations and other tools like Contract4J, SonarJ and Lattix can be used for more comprehensive rules enforcement. The session will include a demo of enforcing architecture rules in a sample Java application using Aspects as well as SonarJ tool. The attendees will be able to take away the techniques and tools discussed in the presentation back to their projects and start using them in their applications right away.
About Srini Penchikala
Srini Penchikala currently works as an Enterprise Architect at a major financial organization in Metropolitan Detroit area. He has over 14 years of IT experience and has been working on Java projects since 1996 and J2EE technology since 2000. His main areas of interest are Agile Enterprise and Service Oriented Architectures, Domain Driven Design & Development In Practice, Aspect-Oriented Programming (AOP), Architecture Rules Enforcement, Enterprise Integration Patterns, and light-weight middleware frameworks such as Spring and Hibernate. He has presented at conferences and Java User Groups on topics like Agile Enterprise Architectures, Architecture Governance, and Domain-Driven Design. He has published numerous articles on J2EE topics on websites like InfoQ.com, ServerSide.com, O'Reilly Java Network (ONJava), DevX Java, java.net and JavaWorld. Srini also publishes a blog on Java, JEE, and other topics at http://srinip2007.blogspot.com/. He is also a leader of Detroit Java User Group (http://sites.google.com/site/detroitjug/).
More About Srini »