Reddit reviews Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
We found 9 Reddit comments about Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Here are the top ones, ranked by their Reddit score.
And of course: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420
http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ref=pd_bxgy_b_text_y
You didn't go into too many details, so I just wanted to make sure you weren't missing the things that make for a a foundation.
I think Domain Driven Design is a good path for you, mainly because it doesn't necessarily over prescribe a technology stack (those are in constant flux) and focuses on the fundamentals of designing for a domain and understanding how to deal with the complexities that come with it.
Eric Evan's book is a great place to start. Personally I have two other books that are incredibly helpful for DDD. The first is Implementing DDD by Vaughn Vernon, and the second is Patterns, Principles, and Practices of DDD. I think the second is a little more along the lines of what you're looking for, but doesn't go into as much of ideas and structures of DDD. What it does do is go into more of the patterns that you're far more likely to see in an enterprise application.
Two patterns that you should pay attention to are Command Query Response Segregation (CQRS) and Event Sourcing. CQRS can be used in a number of ways and incarnations. Event Sourcing may or may not be applicable in your application, but its useful to think of an application's state and interactions as an immutible ledger of events.
If you go down the road of microservices, then I strongly suggest you also explore message queues as well. Although they certainly are useful, microservices are seen as somewhat of a fad or buzzword. Message queues, and the patterns that go with them, are quite useful in this context and also applicable in more "traditional" service oriented architectures as well. A great book for diving into those messaging patterns is Enterprise Integration Patterns.
NoSQL and Big Data solutions will likely come up along the way, and although they are worth exploring in their own right, I think its important that they are implemented for the right reasons. I'll leave this here for now, if this is something that you want to explore further, I'd suggest reading through Fowler's Polygot Persistence as a good jumping off point
Celery’s use of RabbitMQ for communication with workers is just an implementation detail. It works great for distributing functions but it’s not great for data pipelines.
I built a messaging system with a lightweight abstraction over pika. At the time I couldn’t find a library or framework that did what I wanted. If the complexity is too much then I would question your choice of messaging queuing entirely.
I found this book to be a great source of inspiration with my project: https://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683
Senior Level Software Engineer Reading List
Read This First
Fundamentals
Development Theory
Philosophy of Programming
Mentality
Software Engineering Skill Sets
Design
History
Specialist Skills
DevOps Reading List
+1 on those books. Also:
There are integration patterns to solve this. A good book: http://www.amazon.co.uk/Enterprise-Integration-Patterns-Designing-Addison-Wesley/dp/0321200683/ref=sr_1_1?ie=UTF8&qid=1419159967&sr=8-1&keywords=enterprise+integration+patterns
A lot of this is hype, however the is sense underneath and a lot of this is old ideas resurfacing.
Awesome! I kind of fell into the job. I was initially hired as a web developer, and didn't even know what BI was, and then got recruited by one of the BI managers and fell in love. To me, it is one of the few places in IT where what you create will directly impact the choices a business will make.
Most of what I do is ETL work (taking data from multiple systems, and loading them into a single warehouse), with a few cubes (multidimensional data analaysis) and SSRS report models (logical data model built on top of a relational data store used for ad hoc report creation). I also do a bit of report design, and lots of InfoPath 2010 + SharePoint 2010 custom development.
We use the entire Microsoft BI stack here, so SQL Server Integration (SSIS), Analysis (SSAS), and Reporting Services (SSRS). Microsoft is definitely up and coming in the BI world, but you might want to try to familiarize yourself with Oracle BI, Business Objects, or Cognos. Unfortunately, most of these tools are very expensive and not easy to get up and running. I would suggest you familiarize yourself with the concepts, and then you will be able to use any tool to apply them.
For data warehousing, check out the Kimball books:
Here and here and here
For reporting, get good with data visualizations, anything by Few or Tufte, like:
Here and here
For integration, check these out:
Here and here
Also, if you're interested in Microsoft BI (SSIS, SSAS, SSRS) check out this site. It has some awesome videos around SSAS that are easy to follow along with.
Also, check out the MSDN BI Blog: http://blogs.msdn.com/b/bi/
Currently at work, but if you have more questions, feel free to shoot me a message!
Thanks for the detailed reply, it helped fill in a lot of the stuff I was missing by reading the slides (esp regarding XML usage/etc)
So for all intents and purposes, I'm in big enterprise land, I've stayed away from the games industry largely because of the reputation for enormous overtime. The idea of cheap horizontal scaling of distributed systems is not unknown (http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/). I understand the usage of coroutines to reduce the apparent complexity of async code (and I've even done it in twisted), but I guess what I'm driving at is why not just message the next system and be done instead of waiting to resume your function? The subsequent system then dispatches based on the result instead of some form of awaited callback event.
EDIT: exceptions maybe in the case of non-blocking IO calls? But in that case you can still limit the async complexity to just those IO calls and that service but leave the rest as messaging rather than coroutine resumes.