locked
Practical SOA: structuring VS solution RRS feed

  • Question

  • I've Just started to build some template for typical VS solution structure, also my 
    system might not use any external systems, i find benefits in using SOA

    principles  even when the system is monolithic. Please note, this post is
    regarding structuring VS solution, other SOA concepts (such as a-sync flows, ESB)

    are out of scope for now. So, i started with something like the following:  

     

    Folder: businessServiceDefintion (all interfaces of our business services, e.g.
      IMembershipService)
    Folder: Applications (GUI, testing, etc.)
    Folder: Business Module A (e.g. membershipModule)

       Domain/Entities

       Services/Facade
       Interface of repository
    Folder: Business Module B (e.g. billingModule)

       Domain/Entities

       Services/Facade
          Interface of repository

    Folder: Business Module C (e.g. orderModule, orchestrates Modules A & B)
    Folder: Component model (interfaces and bases for entities and services to
      encourage standard code)
    Folder: Data access code - 
      This project wraps some ORM (i use EF) to implement all the neccessary data
      access for all modules(!).
      Because all modules share  the same DB(not realy autonomous...), a single data
      access project is being  used.  Each business module service will be injected with
      concurrent repository - a data access code which wrapes the use of the ORM.   

     

    Please note that each module is autonomous (entities, services and data access
    are all together),  it has all the neccessary resources to operate (unlike N-Tiers style).

    Although i'm not explicitly dealing here with connected systems, i find benefits to
    break monolithic system (a single VS solution) using SOA style:

    1. The solution is a mirror of the business.
    2. Each module is an autonomous sub-system sharing minimal dependencies with
    other business departments.

    3. Each module implements an interface therefore it can be replaced easilt with another provider.

    So, my question is: what do you think about the soltion above ? do you still keep all
    your business logic code  in single project/layer? Do you have better approaches for
    structuring VS solution  with or without SOA principles?

     

    Thanks.

    Tuesday, April 22, 2008 3:44 PM

Answers

  • Well, take a look at the enterprise architecture I have posted in http://gajakannan.com/netarch.aspx  What you are doing is basically a facade of entities in different VS project files.  You can keep the facade on separate project files or one project file.  It depends on how much these objects "chat" with each other, how big your project file is going to be and the benefits of deploying each of them independently without impacting another (I hope you have designed the data contract among each of them to allow reasonable changes in future if required and they are interdependent)...

    Tuesday, April 22, 2008 9:51 PM


  • I would also agree that that looks like a great project setup. 

    Something you mention is that you like to use an SOA setup for single VS solutions, personally I see SOA from a structure and setup perspective to be equatable to a good design.  Loose coupling and so on should be a feature of all solutions regardless of what methodology they're following.  It gives the most flexibility for the backend subsystems.

    I have a few ideas for you, you might want to take a look at the TFS guide for structuring projects if you haven't already, that might give you some further ideas on why you might or might not structure your project in a particular way?  I know that the suggestions are fairly generic, but it's a baseline to test the theories you have against.

    One thing, the component model - you need to make sure that the common base isn't going to couple any of your designs inherently.  I think that I would treat the component model as yet another module, and name it appropriately for the common functionality that it provides (not 'common', or component)  Then if you find some other specific shared functionality, you may use that also, but there isn't a single common point, and instead a module is included as required, one of possibly many shared modules.  The controlling of change in this case should give particular attention to these modules, so perhaps put them in under a shared folder and namespace to make that obvious?

    Think that there could also be some sharing between the data access layer and the business layer, depending upon the design, it could be that the business code and data code share DTO objects, which in your situation would probably be stored in the data acccess module.

    The risk there might be that the assumption that you will only ever have one database access code module might limit the solution perhaps, whereas considering it more as a number of data access modules, of which there currently is only one may get you into the better mindset?

    Just a few thoughts for you.  It's going to change a little project to project, and my approach is usually to start with something  simple and straight forward, and be flexible with arranging projects and the like, as the need arises, move them to a place in the solution that seems more appropriate, as sometimes one size does not fit all circumstances.

    Hope this helps,

    Martin Platt.
    Tuesday, April 22, 2008 10:14 PM

All replies

  • Your solution looks good.  especially when there is less dependency on module A, B and C, it is good to keep them separate.  This also helps the project loading and compile time in VS.
    Tuesday, April 22, 2008 6:10 PM
  • Any other idea, i need some confidence before making this revoluion in my projects structure... Smile

    Tuesday, April 22, 2008 9:38 PM
  • Well, take a look at the enterprise architecture I have posted in http://gajakannan.com/netarch.aspx  What you are doing is basically a facade of entities in different VS project files.  You can keep the facade on separate project files or one project file.  It depends on how much these objects "chat" with each other, how big your project file is going to be and the benefits of deploying each of them independently without impacting another (I hope you have designed the data contract among each of them to allow reasonable changes in future if required and they are interdependent)...

    Tuesday, April 22, 2008 9:51 PM


  • I would also agree that that looks like a great project setup. 

    Something you mention is that you like to use an SOA setup for single VS solutions, personally I see SOA from a structure and setup perspective to be equatable to a good design.  Loose coupling and so on should be a feature of all solutions regardless of what methodology they're following.  It gives the most flexibility for the backend subsystems.

    I have a few ideas for you, you might want to take a look at the TFS guide for structuring projects if you haven't already, that might give you some further ideas on why you might or might not structure your project in a particular way?  I know that the suggestions are fairly generic, but it's a baseline to test the theories you have against.

    One thing, the component model - you need to make sure that the common base isn't going to couple any of your designs inherently.  I think that I would treat the component model as yet another module, and name it appropriately for the common functionality that it provides (not 'common', or component)  Then if you find some other specific shared functionality, you may use that also, but there isn't a single common point, and instead a module is included as required, one of possibly many shared modules.  The controlling of change in this case should give particular attention to these modules, so perhaps put them in under a shared folder and namespace to make that obvious?

    Think that there could also be some sharing between the data access layer and the business layer, depending upon the design, it could be that the business code and data code share DTO objects, which in your situation would probably be stored in the data acccess module.

    The risk there might be that the assumption that you will only ever have one database access code module might limit the solution perhaps, whereas considering it more as a number of data access modules, of which there currently is only one may get you into the better mindset?

    Just a few thoughts for you.  It's going to change a little project to project, and my approach is usually to start with something  simple and straight forward, and be flexible with arranging projects and the like, as the need arises, move them to a place in the solution that seems more appropriate, as sometimes one size does not fit all circumstances.

    Hope this helps,

    Martin Platt.
    Tuesday, April 22, 2008 10:14 PM
  • Another angle to consider is to use your (VS)solutions to isolate the services. So no, don't mix all your isolated services' business layers in the same solution. Consider putting everything about a specific isolated service in it's own solution. It will help re-enforce the isolated ownership and reduce the temptation to make RPC style calls between different services. Obviously you need to 'cut your cloth' appropriately but I thought I'd add my angle to the question.

    http://pauliom.wordpress.com

    Saturday, April 13, 2013 11:45 AM