Successfully reported this slideshow.
Your SlideShare is downloading. ×

What SOA do you have (with extended EDA and CQRS material)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
SOA vs EDA
SOA vs EDA
Loading in …3
×

Check these out next

1 of 124 Ad

What SOA do you have (with extended EDA and CQRS material)

Most companies today use SOA to integrate their systems or mobile applications, or do they?
Join me on a historical trip where we will see how integration has remained stuck in the same patterns and we will also take a look at the emperors new clothes (or SOA as it’s practiced today).
After this we will look at how to do SOA better and the principles that will make this transition possible (keywords: Event Driven Architecture, Domain Driven Design, Composite UI’s and CQRS).
Slides and Video here: http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk/

Most companies today use SOA to integrate their systems or mobile applications, or do they?
Join me on a historical trip where we will see how integration has remained stuck in the same patterns and we will also take a look at the emperors new clothes (or SOA as it’s practiced today).
After this we will look at how to do SOA better and the principles that will make this transition possible (keywords: Event Driven Architecture, Domain Driven Design, Composite UI’s and CQRS).
Slides and Video here: http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk/

Advertisement
Advertisement

More Related Content

More from Jeppe Cramon (19)

Recently uploaded (20)

Advertisement

What SOA do you have (with extended EDA and CQRS material)

  1. 1. Jeppe Cramon What SOA do you have?
  2. 2. Problems with SOA • Systems are more fragile • Development and Maintenance costs are higher • Your services are not being reused • You thought SOA would solve your integration problems, but they’ve gotten worse • No one wants to build or maintain services • System performance is worse
  3. 3. If you have arrived at the realization that SOA is a pain and costs too much without enabling business agility or reducing your costs, you are not the only one. You will have to change your approach to achieve the benefits of SOA
  4. 4. Let’s take a trip back in time
  5. 5. And look at how we could do business
  6. 6. Sales Department Old style SOA Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  7. 7. This is slow
  8. 8. We are not selling enough!!
  9. 9. Sales Department Old style SOA II Design Department Customer Department Finance Department Fabric Department Create Sales Order
  10. 10. We need to speed things up! Hackel walks between desks? Way too slow.
  11. 11. We need to speed things up! He needs to call So we make sure that he can Actually, call a lot!
  12. 12. We need to speed things up! But Hackel still have to wait Even if we get creative
  13. 13. We need to speed things up! Something needs to be done!!
  14. 14. Speed up even more! Lets get an automatic switchboard!
  15. 15. Speed up even more! New technology, same problem Even if we get creative again
  16. 16. Or do things Async So Hackel can send request to Ingeborg and Kresten which can respond to Hackel when they’ve got an answer But even that doesn’t scale well, there’s still only one Ingeborg and Kresten
  17. 17. Speed up even more! So Kresten and Ingeborg adds more staff
  18. 18. Scalability is expensive Sales Department Design Department Customer Department Finance Department Fabric Department Coordinator Hackel
  19. 19. Same problem different technology Data Storage Data Storage Data Storage Finance Service Data Service Design Service Hackel Coordinator Service Hackel Coordinator Service Sales Order Service Sales Order Service Customer Customer Fabric Service Customer Service Data Storage Client Process Service layer Activity Service layer Data Service layer
  20. 20. Resemble much?
  21. 21. Now back to the story… • Scaling up Sales requires scaling up other departments relatively much • People cost money and why have 9 Finance people for every 10 sales people just to answer questions about pricing • There’s got to be a better way to handle this • And there is 
  22. 22. Sales Department Event Driven SOA and local caching Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  23. 23. Scalability is cheaper Sales Department Design Department Customer Department Finance Department Fabric Department
  24. 24. This is just the beginning
  25. 25. Have our mindset changed over the last 40 years?
  26. 26. Paper work, file cabinets and manual workflows Inventory ShippingPurchase Manual workflow Manual workflow
  27. 27. Next step was automating paper forms (aka. The birth of CRUD) Inventory ShippingPurchase Manual workflow Manual workflow
  28. 28. Database integration Inventory ShippingPurchase Database Integration Database Integration
  29. 29. Enterprise Application Integration (EAI) Inventory ShippingPurchase Application Integration Application Integration
  30. 30. WebServices to the Rescue? SOA Web of Mess Inventory Purchase ShippingPortal
  31. 31. ESB’s the the Rescue? SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
  32. 32. ESB Reality SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
  33. 33. I’ve got a cheaper solution
  34. 34. To be clear – none of the examples represent in my opinion SOA 4 tenets of SOA: • Boundaries are explicit • Services share schema and contract, not class • Service compatibility is based on policy • Services are autonomous
  35. 35. What we’ve seen is just old EAI wine on new SOA bottles
  36. 36. Can’t we just avoid Services and make one big application?
  37. 37. Retail Domain Invoicing Subdomain Product Catalog Subdomain Shipping Subdomain Sales (Order) Subdomain Inventory Subdomain Pricing
  38. 38. One Domain Model to Rule them All? Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on everything else
  39. 39. One big model to capture it ALL? …. ….. ….. …. ….. ….. …. ….. ….. …. ….. …..
  40. 40. Result: Our queries get messy
  41. 41. ONE MODEL TO RULE THEM ALL ONE MODEL TO FIND THEM ONE MODEL TO BRING THEM ALL AND IN THE DARKNESS BIND THEM
  42. 42. The database determines our scalability
  43. 43. And databases often scale poorly To solve the performance problems for a few, you have to upgrade it all
  44. 44. Do not design for locality and try to distribute Design for distribution, take advantage of locality
  45. 45. Alternatively we can use Read replicas Master Slave SlaveSlaveSlave You’re now eventually consistent
  46. 46. Or introduce caching… What’s your synchronization mechanism? ?
  47. 47. Many perspectives on data Customer Retail System Pricing Inventory Sales Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle for Data is VERY important! Forecasting?
  48. 48. Smaller models & clear data ownership Sales Product ProductID Name Description Quantity Ordered … Sales Inventory Product ProductID SKU QOH Location Code … Inventory Pricing Product ProductID Unit Price Promotional Price … Pricing DDD: Bounded Context SOA: Service Retail System Shared Entity identity
  49. 49. Autonomy becomes the next (and biggest) problem Can you rely on others?
  50. 50. Data Layer Service Orchestration issue Data Access Layer Service Layer Interface/Display Layer System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema Local transaction spanning all modules Service
  51. 51. Service autonomy Service B Service C Service A System X Service A System Y Service B Service C System X Slow/unreliable network Different SLA Slow system
  52. 52. Orchestration using synchronous communication and local transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema B:Service() call C:Service() call B:DAL() call A:Service() commit() Service
  53. 53. Solution for when going distributed? Can’t we just distributed transactions? (XA / 2 phase commit)
  54. 54. Distributed Transactions…. Oh my Sales system Sale Delivery system Deliveries Customer/CR M system Custome r SAP Bookkeeping Complete Purchase Transaction Coordinator Transactional Resource Prepare Phase Commit Phase 2 Phase Commit
  55. 55. What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous – Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • X Phase Commit is fragile by design
  56. 56. Orchestration using synchronous communication and without distributed transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema ServiceB:Service() call C:Service() call B:DAL() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:DAL AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well) commit()
  57. 57. More of the same clearly can’t be The answer…
  58. 58. The more autonomous services are, the more loosely coupled they are. Loose coupling is what drives business agility – which is why we wanted SOA in the first place
  59. 59. Loose coupling Requires good encapsulation and high cohesion
  60. 60. Return of the SILOS!!!!
  61. 61. We need SMALL SILOS that SHARE very LITTLE with each other Sales Pricing InventoryShipping ✕ ✕ ✕
  62. 62. A silo/bounded-context contains all parts related to it DB Schema Domain Services Application Services Domain Model Aggregates , Entities, Value Objects, Events Integration Endpoints (REST, SOAP, Pub/Sub) User Interface Silo
  63. 63. A silos parts are not limited to deployment at a single location Subdomain User Interface Integration Endpoints (REST, SOAP, Pub/Sub) Domain Services Application Services Aggregates, Entities, Val ue Objects, Ev ents DB Schema Units of individual deployment
  64. 64. What should our silos share? Bounded Context
  65. 65. Degrees of coupling UI UI Service ServiceData Data Events Events
  66. 66. Composite UI’s Retail System Sales Pricing Inventory Web/Application tier Background server tier Storage tier Composite UI UI Layered ApplicationData Access Layer Readmodel Writemodel ✕ ✕
  67. 67. Composite UI - example Context: Book ISBN-10 0-321-12521-5
  68. 68. Composite UI - HTML #DIV – BookReviews #DIV – BookImage #DIV – BookTitleAndAuthor #DIV – BookPricing #DIV – BookAvailability #DIV - Header #DIV - Body
  69. 69. Composite UI
  70. 70. That covers data presentation What about transactions?
  71. 71. Next Step – Event Driven Architecture Sales Product SKU Name Price Quantity Ordered … Inventory Service (SAP) Product SKU QOH Location Code … Pricing Service Product SKU Unit Price Promotional Price … Inventory Pricing Sales Customers Order Accepted Event MessageBus Who coordinates the sales process? Online Ordering System Web Shop (Composite UI) Sales UI
  72. 72. Let’s make the implicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: – CustomerBilled – ParcelShipped – CustomerCreated – ReviewCreated – CommentAdded – CommentDeleted
  73. 73. Domain Events Events allows us to implement Business Processes and quickly alter them That gives us Business Agility
  74. 74. Introducing Choreographing Processes Sales Service Order Accepted Billing Service Shipping Process Manager Shipping Service Online Ordering System MessageBus Order Accepted Order Accepted Customer Billed Customer Billed Order Ready for Shipping Order Ready for Shipping
  75. 75. Business Events Events also allows us to decentralize data in best Master Data Management (MDM) style where necessary data is cached locally in other services to break Like in the Matador example
  76. 76. MDM using Events Note: This solution doesn’t apply the Composite UI due to the nature of the Systems being integrated
  77. 77. Sales Department Event Driven SOA and local caching Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  78. 78. How to support an EDA from within a Bounded Context?
  79. 79. Typical One size fits all ”architecture” Client Remote Facade Application Service Data Access Layer Data Storage Domain Object Domain Object DTO DTO
  80. 80. THE Solution?
  81. 81. Same procedure as last year? Same procedure as every year!!!
  82. 82. Open to new ideas? Paul, you idiot, what's that!? You should only bring things we can eat!
  83. 83. IT exists to support the business by support various usecases Usecases can be categorized as either • ”User” intent to manipulate information • ”User” intent to find and read information We already support this in OO at a Property level: • Setter (or mutator) methods Manipulate data • Getter (or accessor) methods Read data Let’s raise it to a higher Level
  84. 84. CQS Separation of functions that write & functions that read Functions that write are called Command methods and must not return a value Functions that read are called Query methods and must have no side effects
  85. 85. CQS UI Application Domain Data Commands – Change data UI Application Data Queries – Ask for data (no side effects)
  86. 86. CQS from a code perspective public class CustomerService { // Commands void MakeCustomerPreferred(CustomerId) void ChangeCustomerLocale(CustomerId, NewLocale) void CreateCustomer(Customer) void EditCustomerDetails(CustomerDetails) // Queries Customer GetCustomer(CustomerId) CustomerSet GetCustomersWithName(Name) CustomerSet GetPreferredCustomers() } From: https://gist.github.com/1964094
  87. 87. SO WHAT IS CQRS? CQRS is simply the creation of two objects where there was previously only one Greg Young
  88. 88. CQRS In its simplest form public class CustomerWriteService { // Commands void MakeCustomerPreferred(CustomerId) void ChangeCustomerLocale(CustomerId, NewLocale) void CreateCustomer(CreateCustomer) void EditCustomerDetails(CustomerDetails) } public class CustomerReadService { // Queries Customer GetCustomer(CustomerId) CustomerSet GetCustomersWithName(Name) CustomerSet GetPreferredCustomers() } From: https://gist.github.com/1964094
  89. 89. Commands A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Aggregate Commands are stated in the imperative: – DoStuff – CreateCustomer – ShipOrder – AddComment – DeleteComment
  90. 90. Thin Layers of complexity UI Data Pro: Easy and simple Con: Scales poorly for complex domains Language of the database
  91. 91. Next step – more layers UI Application Domain Data Pro: Handles complex domains better by Separating usecase and domain logic Con: Increasing complexity. Risk of Anemic Domain model combined with transaction-script. Time Complexity Language of DTO’s Language of getters and setters Language of ORM magic
  92. 92. Anemic Domain Model The Good parts • All Order logic is called in ONE class • Lower entry level for junior developers The bad parts • Hard to test • Hard to maintain • Code dupliction • An exposed domain model is like walking around without clothes – everyone can access your private parts and violate your invariants
  93. 93. We need a rich domain model Aggregate with Order as Aggregate Root • Order forms our Unit of consistency, which controls our invariants • Order and OrderLines are created, updated and deleted together
  94. 94. LET’S HAVE A LOOK AT A DIFFERENT TYPE OF ARCHITECTURE
  95. 95. Circular architecture Task based UI Domain ModelRead Model
  96. 96. 1. Realization Commands and Queries support very different usecases
  97. 97. A single model cannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
  98. 98. 2. realization Query results contain only data – no logic • Give me the customer with his last 10 orders • Give me the customer with total sum of orders for the last year • Give me the complete order • Give me the shipping status for the order • Give me the customers last review So why go through the domain layer? UI Application Data
  99. 99. Things to think about in relation to Queries • Why take the pain of performing JOINS and/or UNIONS of our nicely normalized Relational Model? • Why not having a completely denormalized data model (or View) to support our Query? • When we completely denormalize our data, do we really need a relational database or could we use a Key/Value- or Document Store? • Do we really need our Read Data to be to the microsecond consistent with our Write data?
  100. 100. So how is this relevant in the real world? Let’s look at a real life scenario
  101. 101. Collaborative domains 1. Read 2. Read 4. Update 3. Coffee time 5. Stale data
  102. 102. We’re working with stale data
  103. 103. We’re always working with stale data! 20 ms 1 ms 100 ms 100 ms100 ms 1 ms 20 ms At this point our data is at least 120 ms stale + Thinking time + thinking time (1000-1500 ms)
  104. 104. LET’S USE STALE DATA TO OUR ADVANTAGE BY OFFLOADING THE DATABASE BY USING OUR READ MODELS UI Application Domain Write model Commands – Change data UI Application Read models Queries – Ask for data (no side effects)
  105. 105. ALL WE NEED IS A GOOD WAY TO SYNCHRONIZE OUR WRITE AND READ MODELS UI Application Domain Write model Commands – Change data UI Application Read models Queries – Ask for data (no side effects)
  106. 106. Let’s make the implicit explicit! The original DDD book left out a very important concept: Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: – CustomerBilled – ParcelShipped – CustomerCreated – ReviewCreated – CommentAdded – CommentDeleted
  107. 107. Commands & Events • Commands mutate Aggregate state which results in one or more Events being issued/published. Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  108. 108. With Domain Events we now have a mechanism to support our denormalized View/Query models
  109. 109. Read model Read model Commands, Events and Query Models Events UI Domain modelQuery model ”AcceptOrder” command ”OrderAccepted” event ”Find all Accepted Orders” Query Commands are Imperative: DoStuff Events are Past tense: StuffDone
  110. 110. Messaging Architectures Most CQRS implementations see Commands and Events as (asynchronous) Messages public class CreateCustomer { public final Guid CustomerId; public final Name CustomerName; … } public class CustomerCreated { public final Guid CustomerId; public final DateTime CreationDateTime; public final Name CustomerName; } Command Event Difference: INTENT
  111. 111. CQRS Building blocks Client Commands Command Bus Sends Command Handlers Modify Repositories Read Write Data store Event Bus Command Services Event Handlers Events Read store Query HandlersQuery Results Queries Query Services Events Domain
  112. 112. LET’S TAKE IT A STEP FURTHER
  113. 113. Event Sourcing Aggregates track their own Domain Events and derive state from them OrderCreated ProductAdded ProductAdded ProductRemoved ProductAdded OrderAccepted Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50
  114. 114. Full CQRS With EventSourcing UI Domain Event Store Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth
  115. 115. public class CustomerCommandHandler { private Repository<Customer> customerRepository; public CustomerCommandHandler(Repository<Customer> customerRepository) { this.customerRepository = customerRepository; } @CommandHandler public void handle(UnsignCustomer cmd) { Customer customer = repository.load(cmd.getCustomerId()); customer.unsign(); } } public class Customer { private boolean signedUp; public void unsign() { if (signedUp) { apply(new CustomerUnsignedEvent()); } } @EventHandler private void handle(CustomerUnsignedEvent event) { signedUp = false; } }
  116. 116. Testing CQRS BDD style @Test public void a_signedup_customer_can_unsign() { UUID customerId = UUID.randomUuid().toString(); FixtureConfiguration fixture = Fixtures.newGivenWhenThenFixture(); fixture.registerAnnotatedCommandHandler( new CustomerCommandHandler(fixture.createGenericRepository(Customer.class)) ); fixture.setAggregateIdentifier(customerId); fixture .given( TestFactory.customerCreatedEvent(customerId), TestFactory.customerSignedUpEvent(customerId) ) .when( TestFactory.unsignCustomerCommand(customerId) ) .expectEvents( TestFactory.customerUnsignedEvent(customerId) ); }
  117. 117. CQRS / BDD Report generated based on the previous test Scenario: A signed-up customer can unsign Given a Customer with id ”abc1234” that has been created and a customer with id ”abc1234” that is signed-up When a request for Customer with id ”abcd1234” to be unsigned is received Then the Customer with id ”abcd1234” is unsigned
  118. 118. SOA / Integration Commands, Queries and Events form natural integration interfaces So integration is backed in from the beginning!
  119. 119. What about Scalability? CAP Theorem • Consistency: All nodes in the cluster see exactly the same data at any point in time • Availability: Failure of a node does not render the entire system inoperative • Partition tolerance: Nodes can still function when communication with other groups of nodes is lost You can’t have all three!
  120. 120. CAP theorem Source: http://bit.ly/QUurnY Strong  Weak  Eventual Consistency ACID systems are hard and expensive to scale Latency concerns Unless you use Pessimistic Locking – all data is stale (and eventual consistent when delivered to the user)
  121. 121. BASE Basically Available Soft-state Eventually consistent Eventually Consistency levels: • Causal consistency: This involves a signal being sent from between application session indicating that a change has occurred. From that point on the receiving session will always see the updated value. • Read your own writes: In this mode of consistency, a session that performs a change to the database will immediately see that change, even if other sessions experience a delay. • Monotonic consistency: In this mode, A session will never see data revert to an earlier point in time. Once we read a value, we will never see an earlier value. See http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for more
  122. 122. CQRS can give us BASE at the architectural level through asynchronous Commands and Events This gives the business and IT control over where to spend money to scale our solution - instead of trying to buy a bigger database server.
  123. 123. Questions? @TigerTeamDK on TwitterEmail: jeppe@tigerteam.dk Web: http://www.tigerteam.dk @jeppec on Twitter

Editor's Notes

  • Tilbudafd.design afd. bederomingrediens listenfor hveringrediensStof for at hørehvordanbehovet for ingredienskanopfyldes (2 rullerrynkebånd)Lager afd. hvornårkan vi levere Pris for henteprisenogsamt give kundeoplysninger (hvadsker der nårregnskaberlukket)?(næsteudvidelseer at de løberrundt med heleingrediens listen - aggregeret service) n+1 problem (pga. genbrugpålavesteniveau)Hvadsker der når design department ellerregnskabafd. erlukket?Design afd. - de kendermaterialer (opskriften) - Daniel (+ Schwan)Stofafd. -  kenderstofstørrelser (2 rulleraf 2m) - IngeborgLager afd. - har vi detpå lager  plus varebestilling -  EstherRegnskabafd. - kenderkunderogderes status + må de fåpåregningellerskal de selvafhente (plus kenderpriserogkunderabatter)      her er en person der kenderkunder + status       en person der kenderpriser - Mads + KrestenSalgafd.- Arnold + Gudrun
  • IntroducererkoordinatorHackel
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • Skrivbord - man går hen til den anden afd. Tungt og langsomtNæste optimering er tlf.Vi kan ringe rundt og gøre det hurtigere, men tlf. er tit optagetMed gammeldags tlf var der et stort switchboardSå vi får tlf. med drejeskive og automatisk switch board, men problemet er stadig det samme - vi venter i tlf. Løsning flere ansatteRør post kan optimere ved at gøre tingene async - men det skalerer stadig ikke
  • The layersaretechnically de-coupled but not in terms of data or temporal.Eachlayer has a technical integration layerthatmakes it harder to understand the correlationsDebugging is made more difficultSingle point of failureLatency is high and scalability is low
  • Deterikkeantalletaf lag i en lasagne der bestemmerhvor god den er
  • Vigtige Pointer:LangtmindrekommunikationRobust overforsygdom/nedbrud. Vi kansælgeselvom vi ikkefår de senestepriserfraIngeborgellerhvis Design afd. Ersyg
  • The beginning of a Change of mind set
  • Human workflow – data double entry (entering data from a screen in Purchase to a screen in Inventory) due to lack of system integration
  • Before we had Human workflow – data double entry (entering data from a screen in Purchase to a screen in Inventory) due to lack of system integrationDatabase integration is fragile and changes to one applications database will often render all integrations with this database invalid, meaning that a lot of application integrations need to be changed.
  • Batch jobs, files, CORBA, COM/DCOM, RMI….To some EAI is the same a Service Oriented Architecture (SOA), but in reality it’s more or less just a more sophisticated variant of database integration. All integration happens in hindsight and you’re prone to many of the same problems as with database integration.
  • WebService focus was on technical integrations and not business integrations (i.e. automatic service “enablement” of CICS transactions) – methods needed to be called in the right order, transactional boundaries blurry, compensations needed to be handled, etc.To some WebServices, in the form of SOAP over HTTP, is the same a Service Oriented Architecture (SOA). WebServices (SOAP over HTTP) is just one way to integrate applications, but adding XML and SOAP to the equation doesn’t automatically turn integration into SOA.
  • In reality the ESB just hides all the old problematic point-to-point integrations. Introducing an ESB can make sense, but it will never make a poorly designed SOA solution better. If applied without changing your approach to SOA it will just be a very expensive cable cover
  • When the various logical models (subdomain models) need to grow to facilitate new features, each conflicting concern will impede the progress of each other.The bigger the change, e.g. adding a new logical model (such as forecasting), the worse the effect will become.
  • Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on everything else
  • Scale up vertically
  • E.g. In an Inventory system a Product (often referred to as an Item) can have manydifferentnamesdepending on where in the lifecycletheyare:An Ordered Item not yetavailable for Sale is called a Back-Ordered ItemAn Item beingReceived is called a Goods ReceivedAn Item in stock is called a Stock ItemAn Item beingconsumed is called a Item Leaving InventoryAn Item beingspoiled or broken is called a Wasted Inventory Item
  • BPO
  • Note that we’re trying to describe the kind of problems you run into and the consequences it has for you
  • Do you want a Slow Module A to determine the performance of Module B/C?Do you want an error/downtime in Module A to affect the availability of Module B?
  • Locking and scaling: If it takes 200 ms to carry out an operation thatusesscaling, the system canmaximum handle 5 concurrentusersFragility: 2,3,4 .... PhaseCommit - 2PC theoryconcludes by saying &quot;and thisdoes not work in reality&quot; - in case of error (eg. Due to timeout while waiting for a resourcecommitphase) youalways end up with having to decidewhattwo do &quot;Halt and manual recovery&quot; or guesswhether it wasgood or bad!Therearebesides timeouts a big problem. At worst, timeouts last very long!
  • Autonomy and organizational unity around the subdomain. Independence on SLA
  • Don’t distribute unless absolutely necessary
  • Data – hard technical and functional couplingService – loose technical but hard functional couplingUI – loose technical and loose functional coupling
  • Use Cases: There is a difference between the static and the dynamic part of a systemThe dynamic part contributes to provides an precisecontext
  • Loose coupling - data and temporalWeb shop can run without the otherbeing online
  • Vigtige Pointer:LangtmindrekommunikationRobust overforsygdom/nedbrud. Vi kansælgeselvom vi ikkefår de senestepriserfraIngeborgellerhvis Design afd. Ersyg
  • We’realwaysending up with the same old model for architecture . The layered approach, which is fine in and of it self, but it needs to held up againstour domain and solution complexityData are still vertical
  • There is nothing new happening – it’s all the same old just a little bit differentPeople do the same every timePeople dare not pursue new ways of doingthingsPeople dare not tryanything newDo the same eachyear, although all the participants aredead
  • Are you open to new ideas?
  • Spaghetti
  • Lasagna
  • [OrderService|registerOrder(...);closeOrder(...);updateAvailablility(...);addToOrder(...)]-&gt;[Order|OrderDate;Amount;Customer|get/setDate();get/setDate();get/setCustomer();get/setOrderLines()], [Order]++-*&gt;[OrderLine|ProductId;UnitPrice;NoOfUnits|get/setProductId();get/setUnitPrice();get/setNoOfUnits()]
  • [OrderService|registerOrder(...);closeOrder(...);updateAvailablility(...);addToOrder(...)]-&gt;[Order|OrderDate;Amount;Customer|update();close();totalAmount()], [Order]++-*&gt;[OrderLine|ProductId;UnitPrice;NoOfUnits|calculateAmount()]
  • From http://www.codeagle.com/blog/2010/03/10/275/
  • Ourread model is structurallyoriented (the usersperspective on the data in the given context)The write model is behaviouraloriented (transaction and consistencyboundaryoriented)
  • Why is this the bestwecan offer – Whyshould theuserbeinterrupted by a technicalconstraint?
  • Commands and Events areimmutable
  • [Order|OrderDate;Amount;Customer|addProduct();removeProduct();ship();...|onProductAdded(..);onProductRemoved(..);onOrderClosed(..);onOrderShipped(..)],[Order]++-*&gt;[OrderLine|ProductId;UnitPrice;NoOfUnits|calculateAmount()]
  • EventStore: Why store only the currentstate of the system.Matureindustries store transactions and calculate the currentstate
  • Wecanassertthatbothwhatweexpectedhappened and nothingelsehappened (the unexpectedbecomesexplicit)
  • This report is generatedbased on the previous test code
  • (but youcanchosewhichare most important to you in the different cases)
  • ACID:Atomic: The transaction is indivisible - either all the statements in the transactionareapplied to the database, or none are.Consistent: The database remains in a consistentstatebefore and aftertransactionexecution.Isolated: While multiple transactionscanbeexecuted by one or more userssimultaneously, onetransactionshould not see the effects of otherconcurrenttransactions.Durable: Once a transaction is saved to the database (an action referred to in database programmingcircles as a commit), itschangesareexpected to persist.

×