Recomendados
Recomendados
Más contenido relacionado
Similar a Why soa DDD South West 6
Similar a Why soa DDD South West 6 (20)
Más de Sean Farmar
Más de Sean Farmar (8)
Último
Último (20)
Why soa DDD South West 6
- 1. Why Service Oriented Architecture? Sean Farmar @farmar
- 2. The Evolution • Small monolith • Success == growth == features ++ • Team Scaling • Maintenance nightmare == high risk • So we end up with …
- 3. Big Ball of Mud
- 4. So I went to my master
- 5. Solve the problem you want? • Coupling your problem is • SOA your solution is
- 6. Why SOA? • SOA's tenets are about reducing coupling.
- 7. • Afferent (dependents) • Efferent (depend on) • Temporal (time, RPC) • Spatial (deployment, endpoint address) • Platform (protocols, .Net Remoting) Coupling
- 8. Coupling: Solutions Platform: •XML on the wire. •XSD (schema) describing XML structure •Use standards based transfer protocol like http •Standards based description of message flow •WSDL (only supports request/response) •SSDL(supports richer semantics)
- 10. Coupling: Solutions Spatial: •Application level code should not need to know where cooperating services are on the network
- 11. In practice
- 12. In practice • Vertical Slicing • Using asynchronous messaging • Using publish subscribe • Business domain decomposition • Explicit intentions [naming, context] • Single Responsibility • Command Query Separation • “Clean Code” (Uncle Bob)
- 14. Vertical Slicing
- 17. Subscribe to Customer Status Updated Publish Customer Status Updated Save status locally Subscribe to Product PricingProduct Pricing UpdatedUpdated Publish Product Pricing Updated Save pricing locally Place Order Publish Order Accepted Sales MarketingCustomer Care
- 18. Summary • SOA • NServiceBus • Particular.net • You can do it
- 19. Learn to build better systems from Udi Dahan Advanced Distributed Systems Design 2 days (out of 5) for FREE Join us at the Particular booth for more information
Notas del editor
- I’ve been hacking code for a living in the last 20 years In 2009 I’ve made a move to Service Oriented Architecture using NServiceBus, it was a paradigm shift that changed the way I do software
- We all probably been there Start with a green field, small monolith, clean design Then the business succeeds, we add features and our clean code gets littered with more code to cater for more features We soon find ourselves dreading change anything…
- You know I went trough this a couple of times, each trying a different approach But the result was always the same… Insanity: doing the same thing over and over again and expecting different results. So I went to my master…
- YODA! What am I doing wrong? I’m doing everything by the book, n-tier, layers and tiers. I even tried web services… Nothing seams to work!
- 1: Boundaries are explicit 2: Services are autonomous 3: Services share schema & contract, not class 4: Service compatibility is based upon policy
- #1: Platform Also known as “Interoperability” Using protocols only available on one platform Remoting, Enterprise Services, Datasets over Web Services One of the famous 4 Tenets: “Share contract and schema, not class or type”
- 1: Boundaries are explicit 2: Services are autonomous 3: Services share schema & contract, not class 4: Service compatibility is based upon policy
- Transactions & Temporal Coupling Asynchronous messaging makes it difficult to have transactions cross boundaries Don’t let transactions flow between services Autonomy means not letting any one lock or modify something that’s yours
- 1: Boundaries are explicit 2: Services are autonomous 3: Services share schema & contract, not class 4: Service compatibility is based upon policy