Loading ...
Sorry, an error occurred while loading the content.
 

DDD and SOA

Expand Messages
  • trondeirikkolloen
    Hi folks Service Oriented Development (SOA) is a very hot topic these days. The hot potato of SOA is to supply groups of functionality in a way that is
    Message 1 of 16 , Aug 29, 2008
      Hi folks

      Service Oriented Development (SOA) is a very hot topic these days.
      The hot potato of SOA is to supply groups of functionality in a way
      that is reusable between traditional barries as applications,
      networks, operating system and development languages.

      It seems for me as SOA is used in several contexes. In the start I
      tought as Services in SOA as a web service. During time I, and others
      I think, is viewing the Service in SOA as group of functionality
      might be utilized between layers in the same system, and not
      nessesarly only between different systems.

      When defining that you have a Service at some location, that will
      also imply some special restrictions, as standardized data transfer,
      fault isolation and more. For example, it is not possible for a
      domain object to travel trought a service.

      What I'm wondering about is what you are thinking about the concept
      of SOA vs. the concept of DDD?
      Are they a perfect match fullilling each other?
      Are they excusion concepts, meaning that if you use DDD you cannot
      use SOA?
      Are they solving/attaching different part of the problem domain?
      Are they solving the same part of the problem domain?
      and so on...

      What do you think?

      Best regards, Trond-Eirik
    • Barry Latimer
      I m not a total DDD expert but work in a company that is heavily focused on SOA to provide services to clients and internal developers. We are starting to move
      Message 2 of 16 , Aug 29, 2008

         

        I’m not a total DDD expert but work in a company that is heavily focused on SOA to provide services to clients and internal developers.

         

        We are starting to move to a DDD philosophy as it tends to fit well with SOA in that DDD natural tends to help group operations and one of the biggest challenges in a web service based SOA environment is to make services that are not too chatty and at the same time not too big to consume.

         

        From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of trondeirikkolloen
        Sent: Friday, August 29, 2008 10:15 AM
        To: domaindrivendesign@yahoogroups.com
        Subject: [domaindrivendesign] DDD and SOA

         

        Hi folks

        Service Oriented Development (SOA) is a very hot topic these days.
        The hot potato of SOA is to supply groups of functionality in a way
        that is reusable between traditional barries as applications,
        networks, operating system and development languages.

        It seems for me as SOA is used in several contexes. In the start I
        tought as Services in SOA as a web service. During time I, and others
        I think, is viewing the Service in SOA as group of functionality
        might be utilized between layers in the same system, and not
        nessesarly only between different systems.

        When defining that you have a Service at some location, that will
        also imply some special restrictions, as standardized data transfer,
        fault isolation and more. For example, it is not possible for a
        domain object to travel trought a service.

        What I'm wondering about is what you are thinking about the concept
        of SOA vs. the concept of DDD?
        Are they a perfect match fullilling each other?
        Are they excusion concepts, meaning that if you use DDD you cannot
        use SOA?
        Are they solving/attaching different part of the problem domain?
        Are they solving the same part of the problem domain?
        and so on...

        What do you think?

        Best regards, Trond-Eirik

        The information contained in this e-mail communication may be confidential. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. If you are not the intended recipient of this e-mail communication, please immediately notify the sender by e-mail and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are those of the individual sender, except where the sender specifically states them to be the views of Ninemsn Pty Limited. Ninemsn Pty Limited does not represent, warrant or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus or interference.

      • moffdub
        I believe you are right in saying that SOA is more than Web Services. Web Services is merely the most powerful application of SOA. My job is a prime example of
        Message 3 of 16 , Aug 29, 2008
          I believe you are right in saying that SOA is more than Web Services.
          Web Services is merely the most powerful application of SOA. My job is
          a prime example of SOA without Web Services, and it is also an example
          of taking it too far.

          Our app is "SOA" in that all of the domain logic is placed into
          service classes, and the domain, or "entity", classes are kept as bags
          of getters, setters, and "isXXXX" methods on purpose. The model is
          extremely anemic. The justification for this is so the entity classes
          can be re-used in other contexts, i.e. used by other "services" in
          application maintained by other teams, and sometimes between our own
          layers.

          The bad part of this is that the code is procedural Java. It is so bad
          that our app has a method buried somewhere that uses reflection to
          look-up all the getters on one class and invoke the corresponding
          setter on another.

          I don't agree with this. I believe DDD and SOA are not mutually
          exclusive. DDD is a way to develop a deployment unit (single app). SOA
          is a way to glue together multiple deployment units.

          Udi Dahan wrote a piece on this topic in Nilsson's DDD book. Here is a
          blog post on the topic as well:
          http://www.udidahan.com/2006/09/04/ddd-the-opposite-of-soa-uh-no/

          So, if you are trying to use SOA with other apps, but you're not using
          Web Services, I think DDD can be applied as-is. Develop your app with
          traditional DDD techniques, minus a UI. In the place of the UI, place
          a *thin* layer of service facades on top of your application layer.

          I think the same applies if you want to apply SOA within different
          layers of your own app. You can certainly write *thin* service facades
          at the boundaries of each layer for the other to use. Domain logic
          should still go into your domain objects / entity objects.

          Of course, your services, no matter how they are incarnated, should
          follow SOA principles like statelessness, composability,
          asynchronicity, interoperability (XML/SOAP for Web Services, DTOs if
          in memory so you can avoid moving domain objects between different
          Bounded Contexts, etc.), discoverability, etc.

          Hopefully this addressed most of your questions.

          --- In domaindrivendesign@yahoogroups.com, "trondeirikkolloen"
          <trond-eirik@...> wrote:
          >
          > Hi folks
          >
          > Service Oriented Development (SOA) is a very hot topic these days.
          > The hot potato of SOA is to supply groups of functionality in a way
          > that is reusable between traditional barries as applications,
          > networks, operating system and development languages.
          >
          > It seems for me as SOA is used in several contexes. In the start I
          > tought as Services in SOA as a web service. During time I, and others
          > I think, is viewing the Service in SOA as group of functionality
          > might be utilized between layers in the same system, and not
          > nessesarly only between different systems.
          >
          > When defining that you have a Service at some location, that will
          > also imply some special restrictions, as standardized data transfer,
          > fault isolation and more. For example, it is not possible for a
          > domain object to travel trought a service.
          >
          > What I'm wondering about is what you are thinking about the concept
          > of SOA vs. the concept of DDD?
          > Are they a perfect match fullilling each other?
          > Are they excusion concepts, meaning that if you use DDD you cannot
          > use SOA?
          > Are they solving/attaching different part of the problem domain?
          > Are they solving the same part of the problem domain?
          > and so on...
          >
          > What do you think?
          >
          > Best regards, Trond-Eirik
          >
        • Luis Abreu
          Hello. I d say that they aren t exclusive at all. I m not sure if anyone will ever be able to give a definitive definition for SOA, but I see it as a way to
          Message 4 of 16 , Aug 30, 2008

            Hello.

             

            I’d say that they aren’t exclusive at all. I’m not sure if anyone will ever be able to give a definitive definition for SOA, but I see it as a way to unify different technologies and expose them as services which can be consumed by others. This doesn’t really prevent me from developing my domain model the way I see fit (which, in most cases, has been based on DDD concepts).

             

            I’m still waiting for what Greg (Young) has to say on his DDDD approach. I’ve seen one presentation which looked really promisingJbut I guess we’re still all waiting to read his wiki on the subject. Btw, anyone knows anything on when it will be available? Greg?

             

            --

            Luis Abreu

             

            From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of trondeirikkolloen
            Sent: sexta-feira, 29 de Agosto de 2008 18:15
            To: domaindrivendesign@yahoogroups.com
            Subject: [domaindrivendesign] DDD and SOA

             

            Hi folks

            Service Oriented Development (SOA) is a very hot topic these days.
            The hot potato of SOA is to supply groups of functionality in a way
            that is reusable between traditional barries as applications,
            networks, operating system and development languages.

            It seems for me as SOA is used in several contexes. In the start I
            tought as Services in SOA as a web service. During time I, and others
            I think, is viewing the Service in SOA as group of functionality
            might be utilized between layers in the same system, and not
            nessesarly only between different systems.

            When defining that you have a Service at some location, that will
            also imply some special restrictions, as standardized data transfer,
            fault isolation and more. For example, it is not possible for a
            domain object to travel trought a service.

            What I'm wondering about is what you are thinking about the concept
            of SOA vs. the concept of DDD?
            Are they a perfect match fullilling each other?
            Are they excusion concepts, meaning that if you use DDD you cannot
            use SOA?
            Are they solving/attaching different part of the problem domain?
            Are they solving the same part of the problem domain?
            and so on...

            What do you think?

            Best regards, Trond-Eirik

            No virus found in this incoming message.
            Checked by AVG - http://www.avg.com
            Version: 8.0.169 / Virus Database: 270.6.13/1641 - Release Date: 29-08-2008 07:07

          • ashley.fernandes@iflexsolutions.com
            Hi All, My Two Cents on SOA, having implemented Web Services, SOA : Design Principle WEB Services : an Implementation of the SOA Design Principle. I correlate
            Message 5 of 16 , Sep 1, 2008

              Hi All,

               

              My Two Cents on SOA, having implemented Web Services,

               

              SOA : Design Principle

               

              WEB Services : an Implementation of the SOA Design Principle.

               

              I correlate the service layer in 3D quite close to the WSDL services exposed by any UDDI. Due to this 3D and SOA co – exist quite well.

               

               

              Thanks & Regards

              Ashley

               

              Oracle logo.gif
              Ashley Fernandes | Consultant | +91 22 6718 7421 (O) +91 9820842428 (M)
              Banking Products Division, Oracle Financial Services

               

              Oracle Financial Services Software Limited was formerly i-flex solutions limited.

               

              From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Barry Latimer
              Sent: Friday, August 29, 2008 11:29 PM
              To: domaindrivendesign@yahoogroups.com
              Subject: RE: [domaindrivendesign] DDD and SOA

               

               

              I’m not a total DDD expert but work in a company that is heavily focused on SOA to provide services to clients and internal developers.

               

              We are starting to move to a DDD philosophy as it tends to fit well with SOA in that DDD natural tends to help group operations and one of the biggest challenges in a web service based SOA environment is to make services that are not too chatty and at the same time not too big to consume.

               

              From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of trondeirikkolloen
              Sent: Friday, August 29, 2008 10:15 AM
              To: domaindrivendesign@yahoogroups.com
              Subject: [domaindrivendesign] DDD and SOA

               

              Hi folks

              Service Oriented Development (SOA) is a very hot topic these days.
              The hot potato of SOA is to supply groups of functionality in a way
              that is reusable between traditional barries as applications,
              networks, operating system and development languages.

              It seems for me as SOA is used in several contexes. In the start I
              tought as Services in SOA as a web service. During time I, and others
              I think, is viewing the Service in SOA as group of functionality
              might be utilized between layers in the same system, and not
              nessesarly only between different systems.

              When defining that you have a Service at some location, that will
              also imply some special restrictions, as standardized data transfer,
              fault isolation and more. For example, it is not possible for a
              domain object to travel trought a service.

              What I'm wondering about is what you are thinking about the concept
              of SOA vs. the concept of DDD?
              Are they a perfect match fullilling each other?
              Are they excusion concepts, meaning that if you use DDD you cannot
              use SOA?
              Are they solving/attaching different part of the problem domain?
              Are they solving the same part of the problem domain?
              and so on...

              What do you think?

              Best regards, Trond-Eirik

              The information contained in this e-mail communication may be confidential. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. If you are not the intended recipient of this e-mail communication, please immediately notify the sender by e-mail and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are those of the individual sender, except where the sender specifically states them to be the views of Ninemsn Pty Limited. Ninemsn Pty Limited does not represent, warrant or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus or interference.

              DISCLAIMER:
              This message contains privileged and confidential information and is intended only for an individual named. If you are not the intended recipient, you should not disseminate, distribute, store, print, copy or deliver this message. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

            • trondeirikkolloen
              Based on the feedback I m getting it seems as if the general interpredation is that SOA and DDD is a nice match that can very well coexists and enricht each
              Message 6 of 16 , Sep 3, 2008
                Based on the feedback I'm getting it seems as if the general
                interpredation is that SOA and DDD is a nice match that can very well
                coexists and enricht each other.

                I'm having a bit of practical question as to how these should be
                paired tougheter.
                Does anyone have an nice example (code or diagrams) of how these are
                technices are combined?

                Hopefully someone has something that they would like to post.
                If not I will se if I can come up with a live-cycle example that can
                function as a discussion base.

                Regards, TEK

                --- In domaindrivendesign@yahoogroups.com, "trondeirikkolloen" <trond-
                eirik@...> wrote:
                >
                > Hi folks
                >
                > Service Oriented Development (SOA) is a very hot topic these days.
                > The hot potato of SOA is to supply groups of functionality in a way
                > that is reusable between traditional barries as applications,
                > networks, operating system and development languages.
                >
                > It seems for me as SOA is used in several contexes. In the start I
                > tought as Services in SOA as a web service. During time I, and
                others
                > I think, is viewing the Service in SOA as group of functionality
                > might be utilized between layers in the same system, and not
                > nessesarly only between different systems.
                >
                > When defining that you have a Service at some location, that will
                > also imply some special restrictions, as standardized data
                transfer,
                > fault isolation and more. For example, it is not possible for a
                > domain object to travel trought a service.
                >
                > What I'm wondering about is what you are thinking about the concept
                > of SOA vs. the concept of DDD?
                > Are they a perfect match fullilling each other?
                > Are they excusion concepts, meaning that if you use DDD you cannot
                > use SOA?
                > Are they solving/attaching different part of the problem domain?
                > Are they solving the same part of the problem domain?
                > and so on...
                >
                > What do you think?
                >
                > Best regards, Trond-Eirik
              • Tomas Karlsson
                Hi, I am developing some combination of DDD and SOA right now. I cannot share any code, but I can share a description on how to do. I am writing code in
                Message 7 of 16 , Sep 3, 2008
                  Hi,
                   
                  I am developing some combination of DDD and SOA right now. I cannot share any code, but I can share a description on how to do. I am writing code in Java/JEE/Hibernate - so there will be some EJB stuff in my solution :-)
                   
                  First of all, develop med domain (pure DDD). Both entities and value objects. Annotation used are @Entity and @Embeddable (with @Embedded when used) for the value objects. Details in the OR-mapping can take some time to figure out, but that is not the interesting thing in the relation to SOA.
                   
                  Assume there is an entity Customer. Then I have implemented the following session-beans:
                   
                  - Stateless session bean CreateCustomer with create(...) methods. The argument lists correspond to the different way one can create a customer instance. Within the bean, the actual entity is created and persisted. Nothing strange with that.
                   
                  - Stateful session bean UpdateCustomer with two lifecycle methods find(customerId) and persist(). Initialize the bean by fin(...) to load the customer to work with into an instance variable in the bean. All business methods used to update a customer are also exposed in the session bean. So if customer has setAddress(...), the same method signature is found in the bean. The internal code is something like (in the UpdateCustomerBean class):
                   
                  public void setAddress(...) {
                      this.customer.setAddress(...);
                      // Side-effect go here!
                  }
                   
                  This is trivial proxy code. However, there is a reason for not using disconnected objects: if there is a side-effect (typically a message on a JMS topic) on certain changes, it cannot be executed successfully if customer.setAddress(...) is executed outside the EJB container.
                   
                  - Stateless session bean RetrieveCustomer with methods like find(custoemrId), findByName(name) etc. The number will increase. We have used Hibernate Search to create an index and allow a more Google-style seach method. That is great :-)
                   
                  All fins methods return List<Customer>. We return the entity as it is. Not any DTO variant of it. Why? Because we don't want duplicate implementation of the same thing. And if a clien executes some operation changing the customer object, it client will not be able to update anyway. There is no update(customer) method anywhere!!!
                   
                  - FInally, stateless session bean DeleteCustomer (if you allow deletion, but you will need it for test anyway). At least delete(customerId) and deleteAll() are expected to be found here.
                   
                  So, four session beans for the CRUD operations. We have found this naming convention nice to work with in two projects. An alternative is just a CustomerManager, but that will be hard if you go for the stateful alternative for update. (This is nice if you want to avoid touching the database at every change.)
                   
                  There is a more advanced style with CreateUpdateCustomer in one stateful session bean. The idea is to "start" the session bean with either creation of a new object or by loading an existing object from the database. Then update and finally persiste. This requires a flag since EJB makes a difference between save and merge (while Hibernate Session class has a method saveOrUpdate - but that cannot be used with the EntityManager in EJB.)
                   
                  And the result? A service (or a set of services if you want) with a very clear resonsibility: doing the back-end part of CRUD on a customer. Having such a service early will add stability early in the project. I one project we had requirements on live update of user interfaces. The solution was a JMS topic where we published information changes. The UI and production of information were fully separated. This payed off when we, later, added another producer of information.
                   
                  I know, just a lot of words... Do you think I should spend some time on example code instead?
                   
                  /Tomas


                  Från: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] För trondeirikkolloen
                  Skickat: den 3 september 2008 10:04
                  Till: domaindrivendesign@yahoogroups.com
                  Ämne: [domaindrivendesign] Re: DDD and SOA

                  Based on the feedback I'm getting it seems as if the general
                  interpredation is that SOA and DDD is a nice match that can very well
                  coexists and enricht each other.

                  I'm having a bit of practical question as to how these should be
                  paired tougheter.
                  Does anyone have an nice example (code or diagrams) of how these are
                  technices are combined?

                  Hopefully someone has something that they would like to post.
                  If not I will se if I can come up with a live-cycle example that can
                  function as a discussion base.

                  Regards, TEK

                  --- In domaindrivendesign@ yahoogroups. com, "trondeirikkolloen" <trond-
                  eirik@...> wrote:

                  >
                  > Hi
                  folks
                  >
                  > Service Oriented Development (SOA) is a very hot topic
                  these days.
                  > The hot potato of SOA is to supply groups of functionality
                  in a way
                  > that is reusable between traditional barries as applications,
                  > networks, operating system and development languages.
                  >
                  >
                  It seems for me as SOA is used in several contexes. In the start I
                  >
                  tought as Services in SOA as a web service. During time I, and
                  others
                  > I think, is viewing the Service in SOA as group of functionality
                  > might be utilized between layers in the same system, and not
                  >
                  nessesarly only between different systems.
                  >
                  > When defining that
                  you have a Service at some location, that will
                  > also imply some special
                  restrictions, as standardized data
                  transfer,
                  > fault isolation and
                  more. For example, it is not possible for a
                  > domain object to travel
                  trought a service.
                  >
                  > What I'm wondering about is what you are
                  thinking about the concept
                  > of SOA vs. the concept of DDD?
                  > Are
                  they a perfect match fullilling each other?
                  > Are they excusion concepts,
                  meaning that if you use DDD you cannot
                  > use SOA?
                  > Are they
                  solving/attaching different part of the problem domain?
                  > Are they solving
                  the same part of the problem domain?
                  > and so on...
                  >
                  > What
                  do you think?
                  >
                  > Best regards, Trond-Eirik

                • Colin Jack
                  ... Only example I know if is a .NET one: http://www.codeplex.com/neuparts Its not very complete though and whether there is enough there to base a discussion
                  Message 8 of 16 , Sep 7, 2008
                    > Hopefully someone has something that they would like to post.
                    > If not I will se if I can come up with a live-cycle example that can
                    > function as a discussion base.

                    Only example I know if is a .NET one:

                    http://www.codeplex.com/neuparts

                    Its not very complete though and whether there is enough there to base
                    a discussion on, not sure.
                  • Colin Jack
                    ... I certainly think they can work together (though I ve never really tried) but if so I think it does need to be done carefully. I say this because although
                    Message 9 of 16 , Sep 7, 2008
                      > Based on the feedback I'm getting it seems as if the general
                      > interpredation is that SOA and DDD is a nice match that can very
                      > well coexists and enricht each other.

                      I certainly think they can work together (though I've never really
                      tried) but if so I think it does need to be done carefully.
                      I say this because although SOA doesn't say much about how you
                      implement your services, how you structure your domain logic, it does
                      impose other constraints.

                      In particular the whole idea of entity services seems to me to be at
                      odds with DDD.

                      Thomas Erl sees these entity services as being a key part of an SOA
                      particularly because they are very reusable, and from what I remember
                      of "Enterprise SOA" they also see them as key but call them data-
                      centric services.

                      In his latest book (3rd of a 300 book series it seems) Erl talks about
                      having entity services for things such as Customer/Order and they'd
                      handle CRUD and more complex logic. You'd then have common schemas
                      (e.g. Customer.xsd) and these schemas would be reused every single
                      time you want to use that entity within a particular part of the
                      enterprise (Domain Inventory pattern). So if you want Customer data
                      you go to that CustomerService and if you want to represent a customer
                      in another place (as in within a message passed to another service)
                      then you'd re-use the common Customer schema.

                      My problem is that I don't see those entity services fitting cleanly
                      with DDD, even if you only expose those services for aggregates you've
                      still got issues because your domain design is going to have to change
                      and you've lost basic features like cross-aggregate transactions. I
                      know you can loosen these things up, but if you do then are you really
                      getting the benefits of SOA?

                      So instead of taking SOA down to the lower levels I'm thinking that
                      you are better to expose large services that each encapsulate entire
                      domain models and then use messaging between these services. Udi Dahan
                      has posted about this a few times, here's one of his articles on it:

                      http://msdn.microsoft.com/en-us/arcjournal/bb245672.aspx

                      I'm interested to know if I've totally missed the point somewhere
                      though.
                    • Casey Charlton
                      ... you are better to expose large services that each encapsulate entire domain models and then use messaging between these services.
                      Message 10 of 16 , Sep 8, 2008
                        >>>So instead of taking SOA down to the lower levels I'm thinking that
                        you are better to expose large services that each encapsulate entire
                        domain models and then use messaging between these services.<<<
                         
                        This is what SOA is when done properly ... any more granular level breaks the "coarse grained services" rule ... CRUD operations certainly have no place in an SOA architecture...

                        2008/9/7 Colin Jack <colinjack@...>

                        > Based on the feedback I'm getting it seems as if the general
                        > interpredation is that SOA and DDD is a nice match that can very
                        > well coexists and enricht each other.

                        I certainly think they can work together (though I've never really
                        tried) but if so I think it does need to be done carefully.
                        I say this because although SOA doesn't say much about how you
                        implement your services, how you structure your domain logic, it does
                        impose other constraints.

                        In particular the whole idea of entity services seems to me to be at
                        odds with DDD.

                        Thomas Erl sees these entity services as being a key part of an SOA
                        particularly because they are very reusable, and from what I remember
                        of "Enterprise SOA" they also see them as key but call them data-
                        centric services.

                        In his latest book (3rd of a 300 book series it seems) Erl talks about
                        having entity services for things such as Customer/Order and they'd
                        handle CRUD and more complex logic. You'd then have common schemas
                        (e.g. Customer.xsd) and these schemas would be reused every single
                        time you want to use that entity within a particular part of the
                        enterprise (Domain Inventory pattern). So if you want Customer data
                        you go to that CustomerService and if you want to represent a customer
                        in another place (as in within a message passed to another service)
                        then you'd re-use the common Customer schema.

                        My problem is that I don't see those entity services fitting cleanly
                        with DDD, even if you only expose those services for aggregates you've
                        still got issues because your domain design is going to have to change
                        and you've lost basic features like cross-aggregate transactions. I
                        know you can loosen these things up, but if you do then are you really
                        getting the benefits of SOA?

                        So instead of taking SOA down to the lower levels I'm thinking that
                        you are better to expose large services that each encapsulate entire
                        domain models and then use messaging between these services. Udi Dahan
                        has posted about this a few times, here's one of his articles on it:

                        http://msdn.microsoft.com/en-us/arcjournal/bb245672.aspx

                        I'm interested to know if I've totally missed the point somewhere
                        though.


                      • Colin Jack
                        ... Excellent. For me that s why its so confusing that so many books/articles/posts/discussions on SOA focus so much on the CRUD style services and talk about
                        Message 11 of 16 , Sep 8, 2008
                          > This is what SOA is when done properly ... any more granular level
                          > breaks the "coarse grained services" rule ... CRUD operations
                          > certainly have no place in an SOA architecture...

                          Excellent. For me that's why its so confusing that so many
                          books/articles/posts/discussions on SOA focus so much on the CRUD
                          style services and talk about them being the core of SOA (and at the
                          same time seem to ignore the very idea of employing a domain model).

                          The authors/bloggers don't even seem to accept the idea that there are
                          other ways of approaching enterprise development, which is a real pity.
                        • Casey Charlton
                          Lots of people make SOA up ... cos it s just a bit of a marketing term really ... :) I view SOA as a series of domains, that each provide coarse grained
                          Message 12 of 16 , Sep 8, 2008
                            Lots of people make SOA up ... cos it's just a bit of a marketing term really ...  :)
                             
                            I view SOA as a series of domains, that each provide coarse grained services to other domains ...  those can each be done with DDD or any other methodology, the point is the services are a facade, so behind the service you can use any old architecture or methodology you like ...

                            2008/9/8 Colin Jack <colinjack@...>

                            > This is what SOA is when done properly ... any more granular level
                            > breaks the "coarse grained services" rule ... CRUD operations
                            > certainly have no place in an SOA architecture...

                            Excellent. For me that's why its so confusing that so many
                            books/articles/posts/discussions on SOA focus so much on the CRUD
                            style services and talk about them being the core of SOA (and at the
                            same time seem to ignore the very idea of employing a domain model).

                            The authors/bloggers don't even seem to accept the idea that there are
                            other ways of approaching enterprise development, which is a real pity.


                          • Andreas Ohlund
                            Bill Poole has an extreemly good blog about SOA inn general that I can recommended. This is what hi has to say about SOA + DDD
                            Message 13 of 16 , Sep 8, 2008
                              Bill Poole has an extreemly good blog about SOA inn general that I can
                              recommended.

                              This is what hi has to say about SOA + DDD

                              http://bill-poole.blogspot.com/2008/04/domain-modelling.html

                              In short: DDD is for bulding the domain logic within coarse grained SOA-
                              services

                              --- In domaindrivendesign@yahoogroups.com, "Colin Jack" <colinjack@...>
                              wrote:
                              >
                              > > This is what SOA is when done properly ... any more granular level
                              > > breaks the "coarse grained services" rule ... CRUD operations
                              > > certainly have no place in an SOA architecture...
                              >
                              > Excellent. For me that's why its so confusing that so many
                              > books/articles/posts/discussions on SOA focus so much on the CRUD
                              > style services and talk about them being the core of SOA (and at the
                              > same time seem to ignore the very idea of employing a domain model).
                              >
                              > The authors/bloggers don't even seem to accept the idea that there are
                              > other ways of approaching enterprise development, which is a real
                              pity.
                              >
                            • Colin Jack
                              ... Its a pity it hasn t moved on from being like that, mind you it s a strong enough term for Thomas Erl to be on his way to 10 books on it:
                              Message 14 of 16 , Sep 8, 2008
                                > Lots of people make SOA up ... cos it's just a bit of a marketing
                                > term really ... :)

                                Its a pity it hasn't moved on from being like that, mind you it's a
                                strong enough term for Thomas Erl to be on his way to 10 books on it:

                                http://www.amazon.co.uk/Service-Oriented-Architecture/lm/R1Z498Y9GVOVZS/ref=cm_lmt_dtpa_f_1_rdssss0


                                > I view SOA as a series of domains, that each provide coarse grained
                                > services to other domains ... those can each be done with DDD or
                                > any other methodology, the point is the services are a facade, so
                                > behind the service you can use any old architecture or methodology
                                > you like ...

                                This makes perfect sense, how about the highly granular (including
                                CRUD) behavior though? Do you still funnel this through web services
                                following the DTO out message in approach?

                                Also what are the best resources you've found on this style of SOA,
                                doesn't seem like there is as much chat about it...
                              • Casey Charlton
                                ... CRUD) behavior though? Do you still funnel this through web services following the DTO out message in approach?
                                Message 15 of 16 , Sep 8, 2008
                                  >>>This makes perfect sense, how about the highly granular (including
                                  CRUD) behavior though? Do you still funnel this through web services
                                  following the DTO out message in approach?<<<
                                   
                                  Well yes, but I don't see CRUD over web services as playing a part in an SOA architecture - to me CRUD services should be intra-application services only ... usually for crossing a firewall, for security concerns or for load balancing ...
                                  >>>Also what are the best resources you've found on this style of SOA,
                                  doesn't seem like there is as much chat about it...<<<
                                   
                                  Little that comes to mind at the moment ... the general problem is that SOA falls into the domain of the "Enterprise Architect" - and Enterprise Architects don;t code and know little about coding ...  so they mostly talk in terms of theory rather than practice ... hence why the people actually doing the coding then slip into CRUD services and the Architects still claim it is SOA ...
                                   
                                   


                                   
                                  2008/9/8 Colin Jack <colinjack@...>

                                  > Lots of people make SOA up ... cos it's just a bit of a marketing
                                  > term really ... :)

                                  Its a pity it hasn't moved on from being like that, mind you it's a
                                  strong enough term for Thomas Erl to be on his way to 10 books on it:

                                  http://www.amazon.co.uk/Service-Oriented-Architecture/lm/R1Z498Y9GVOVZS/ref=cm_lmt_dtpa_f_1_rdssss0


                                  > I view SOA as a series of domains, that each provide coarse grained
                                  > services to other domains ... those can each be done with DDD or
                                  > any other methodology, the point is the services are a facade, so
                                  > behind the service you can use any old architecture or methodology
                                  > you like ...

                                  This makes perfect sense, how about the highly granular (including
                                  CRUD) behavior though? Do you still funnel this through web services
                                  following the DTO out message in approach?

                                  Also what are the best resources you've found on this style of SOA,
                                  doesn't seem like there is as much chat about it...


                                • Colin Jack
                                  ... Good link ta, does look like there is a general theme regarding how SOA & DDD can fit together (big services, doamin within service, not for CRUD). I think
                                  Message 16 of 16 , Sep 9, 2008
                                    > Bill Poole has an extreemly good blog about SOA inn general that I can
                                    > recommended.
                                    >

                                    Good link ta, does look like there is a general theme regarding how
                                    SOA & DDD can fit together (big services, doamin within service, not
                                    for CRUD).

                                    I think I might post on the SOA group because I'd be interested in how
                                    many of them use DDD & SOA together.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.