Announcement Announcement Module
No announcement yet.
Domain Driven Design, Implementations and Testing Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Domain Driven Design, Implementations and Testing


    I'm working on reorganizing my project. I think I've decided on the following structure:

    web (WAR)
    facade/service/api (JAR)
    common-services (JAR or multiple JARs)
    domain (JAR)

    My domain JAR will contain all domain-related objects. This includes: entities, values, services (DDD not SOA), service implementations, and repositories (no implementations). The domain JAR will have no dependencies on any other (internal) JARs.

    My dal JAR will contain repository implementations and any hibernate/jdbc specific classes. It will be dependent on the domain JAR.

    My api JAR will contain the thin-layer API to be used by the web WAR. It will be dependant on common-services, domain and dal.

    My questions revolve around applicationContext placement, wiring and testing of my domain JAR:

    Originally I was thinking that I would have an applicationContext in my domain JAR that would wire together all objects other than the repository implementations. The dal JAR would contain an applicationContext that would wire in the hibernate repository implementations. The api JAR would contain an applicationContext that pulls in the applicationContexts from domain and dal. My reasoning for having separate contexts for domain and dal were that I felt domain should be able to stand on it's on: it should come fully wired (sans repository implementations).

    Then I started thinking about testing. Unit testing is no problem. I can test my entities and services using mocks when necessary. Repositories, however were a different animal as their implemention is unknown to the domain. It seemed to me that I should have SOME integration testing being performed on the domain JAR, testing the wiring contained within, but if so, what would I use for the repositories? Do I create stub implementations just to satisfy the domain integration tests and then run the tests again somewhere else with the dal? Or perhaps the repositories should be mocked during domain integration testing and then the REAL integration testing will occur in the api JAR (which has knowledge of all other JARs).

    I'm leaning towards this last approach at the moment. It feels a bit funny having mocks inside my domain integration tests, but when I think about it, I'm performing tests on the integration of objects within that JAR, but still testing that JAR in isolation, so it might make sense to mix the two.

    I am also thinking that the dal should not contain the applicationContext to wire the hibernate implementations in, but rather place that in the api.

    I guess I want to know how other people have been tackling this common situation and what your experiences and suggestions might be.


  • #2
    I've been using pretty much the same setup for a while and agree on the integration testing part. You could supply a spring context just for testing in the proper layer/module and wire things up in the web app for production use.



    • #3

      Thanks for your reply! I also found many people discussing this topic over at the Domain Driven Design forum:
      They seem to also be going with a similar approach.